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


Channel log from 5 November 2013   (all times are UTC)

00:00leio has left IRC (leio!~leio@gentoo/developer/leio, Remote host closed the connection)
00:02leio has joined IRC (leio!~leio@gentoo/developer/leio)
00:03cliebow_ has left IRC (cliebow_!~cliebow@66.63.66.218, Quit: This computer has gone to sleep)
00:58ChadLepto has left IRC (ChadLepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net, *.net *.split)
00:59ChadLepto has joined IRC (ChadLepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net)
01:30Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
01:31Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 240 seconds)
02:20vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
02:23leio has left IRC (leio!~leio@gentoo/developer/leio, Ping timeout: 245 seconds)
03:04leio has joined IRC (leio!~leio@gentoo/developer/leio)
03:05F-GT has left IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net, Quit: Leaving)
03:12vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
03:21david007co2 has left IRC (david007co2!~androirc@186.28.209.238, Read error: Connection reset by peer)
03:23Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas, Ping timeout: 240 seconds)
03:35david007co2 has joined IRC (david007co2!~androirc@186.28.209.238)
03:38F-GT has joined IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net)
04:13willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
05:03david007co2 has left IRC (david007co2!~androirc@186.28.209.238, Ping timeout: 252 seconds)
05:04Enslaver has left IRC (Enslaver!~Enslaver@fedora/Enslaver, Ping timeout: 272 seconds)
07:10Enslaver has joined IRC (Enslaver!~Enslaver@fedora/Enslaver)
07:20mikkel has joined IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net)
07:25mikkel has left IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net, Quit: Leaving)
07:31mikkel has joined IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net)
07:32alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:39Enslaver has left IRC (Enslaver!~Enslaver@fedora/Enslaver, Read error: Connection reset by peer)
07:41alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 248 seconds)
07:42Enslaver has joined IRC (Enslaver!~Enslaver@fedora/Enslaver)
08:04khildin has joined IRC (khildin!~khildin@ip-213-49-84-217.dsl.scarlet.be)
08:35sd34 has joined IRC (sd34!4f281bd5@gateway/web/freenode/ip.79.40.27.213)
08:35
<sd34>
hi
08:35
yesterday I tried using LTSP installing Edubuntu on my very hard drive, to no avail :(
08:36
same error as before: looping configuration
08:36
<alkisg>
Is that with ltsp-live?
08:36
<sd34>
is there anything I may be doing inadvertently wrong
08:37
yes, I download LTSP from software centre and only LTSP-live was available for download
08:37
<alkisg>
Uninstall it and install ltsp-server-standalone instead
08:37
<sd34>
I couldn't find it on my Software Center, I will get it with the terminal
08:38
<alkisg>
I think software center might have some search issues if you use italian
08:38
<sd34>
I only queried "LTSP"
08:38
<alkisg>
LANG=en_US.UTF_8 software-center might help with the search issues
08:38
Or just use the command line..
08:38
<sd34>
command line if it can fetch from repositories will do just fine for me
08:39
<alkisg>
Ah, I see it:
08:39
When you search for ltsp, you get a few results,
08:39
and in the bottom, it says "show 38 technical packages"
08:39
<sd34>
I noticed that after using LTSP-live my network connection behaves strangely. I will thoroughly remove LTSP-live
08:39
<alkisg>
(translated from greek, I don't know the english wording)
08:39
<sd34>
oh thanks! Didn't notice
08:39
<alkisg>
So if you click there, it does show ltsp-server-standalone
08:40
<sd34>
wonderful, thanks
08:40
<alkisg>
stgraber, highvoltage: anyone knows how to tag "ltsp-server-standalone" as a "non-technical" package, so that it shows up in software-center?
08:40
Maybe it needs a .desktop file in applications/ ?
08:40
<sd34>
Edubuntu guys should be aware of this strange behaviour because their distro ships with LTSP-live..
08:41* alkisg hasn't used edubuntu in a very long time... clean ubuntu with ltsp on top of it
08:42
<sd34>
oh I see
08:42
I showed edubuntu to a school teacher and she liked it very much because of the good software on it
08:42
I may pick their favourites and install them on a plain Ubuntu installation though
08:43
<alkisg>
Yeah installing a bunch of packages is just an apt-get install away, easy...
08:44
<sd34>
indeed
08:44
<alkisg>
Here we even have meta-packages that install all packages for a specific level of education, primary, secondary etc
08:44
I think edubuntu has such packages too, you could use those
08:44
<sd34>
yes, there are 5 or 6 of them
08:45
you can choose which to install in the installation wizard
08:45
is thanking enough? :) I will update you
08:46
eukaristo
08:46
<alkisg>
Hehe, prego :)
08:47
sd34: you might also want to see this:
08:47
!ltsp-pnp
08:47
<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
08:47
<alkisg>
It makes maintaining ltsp *much* easier for teachers...
08:48
<sd34>
I heard of it, it automatically recognizes client computation power and rams so as to make them fat or thin, is that right?
08:48
<alkisg>
Right, but the most important thing is that it doesn't require command line to install progams
08:48
*programs
08:48
It mirrors whatever you installed to the server, to the chroot
08:49
<sd34>
that's super
08:49
has that got its own server package to install or ltsp-server-standalone is required?
08:50
<alkisg>
The instructions there include everything that's necessary
08:50
It's using ltsp-server-standalone, it's an upstream method with the same code base
08:51
So if you start with a clean ubuntu installation and follow that page, you're ready
08:51
<sd34>
thanks a lot, I guess that will be my choice
08:52
<alkisg>
Some quick hints to keep in mind for the future:
08:52
clients with 128 to 400 ram => thin
08:52
> 400 ram => fat
08:52
If you have more than 2-3 thin clients, gigabit switch is required, 60€
08:52
And you also need a good server, e.g. dual core
08:53
If you have only fat clients, then you don't need a very good server, e.g. single core with 1 gb ram is the minimum,
08:53
and the gigabit switch is a little less important,
08:53
(but preferred),
08:54
and there's also a method to copy the virtual ltsp image (chroot) to the clients hard disk (e.g. in C:\Boot\LTSP\i386.img) so that a gigabit switch isn't required at all,
08:54
<sd34>
a former LAN network with a decent switch should be fine, shouldn't it? And the more the fat clients the less powerful server needed, right?
08:54
<alkisg>
And finally, if your clients ram is low, you might want to use gnome-fallback or lubuntu
08:54
If "former lan network" is 100 mbit, then you need gigabit if you have thin clients
08:54
So you'll need a switch
08:54
<sd34>
that's great idea! Light ubuntu and all the software required
08:55
<alkisg>
About fats/less powerfull server, yeah
08:55
gnome-fallback is light too, try that first
08:55
<sd34>
gnome-fallback, I'll write that down
08:55
<alkisg>
If you have the exact clients specs, you can ping me to suggest the best solution to you
08:56
<sd34>
if I happen to know them I will ping you :)
08:56
<alkisg>
In general, <= P3, make them thin clients, >= P4, put >=512 ram and make them fat
08:56
(1 gb preferred)
08:57
lubuntu is only good for fat clients with 256-512 ram, don't use it if you can buy ram
08:57
<sd34>
I already know we can't lol
08:57
but gnome-fallback + ltsp-pnp + education packages would make a brilliant match
08:58Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212)
08:58
<sd34>
I still have to try ltsp-pnp, but if it mirrors everything from server to clients that's much easier for teachers for real
09:01
<alkisg>
As Hyperbyte said, don't stick to the "we can't" :) You'll see that in many cases, schools are willing to give just a few euros for switch, RAM etc if it makes their clients work 5-10 times faster
09:01* alkisg has experience from more than 500 schools for that :)
09:02
<sd34>
you're right
09:02bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 246 seconds)
09:03
<Fenuks>
alkisg: Where did you find those schools?
09:03
<sd34>
hopefully it won't be necessary but if it happens headmaster might allow some spare cash
09:03
<alkisg>
Fenuks: http://www.ltsp.org/stories/widget-map/?location=Greece
09:03
(half of them are there...)
09:04bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:04* alkisg is a teacher, and also somewhat in charge of ltsp installations here in 2 other work-related roles of his...
09:04
<sd34>
my aunt is a teacher and she sometimes explain how on a budget they are so when I found out Edubuntu existed I just told her about it
09:04
<Fenuks>
Lucky you. In Russian Federation they'd prefer to find the cheapest way possible
09:04
<alkisg>
Fenuks: same here, that's the cheapest way possible
09:05
The authorities that give the money also agree to that
09:05
<sd34>
alkisg does epoptes work over ltsp too?
09:05
<Fenuks>
alkisg: My LTSP server is an average intel i3 with 4G RAM I took from one of the classes )=
09:05* highvoltage has seen it work on ltsp and it works exceptionally well
09:06
<alkisg>
Yup, we developed it ourselves for our ltsp installations and then internationalized it for everyone...
09:06
<Fenuks>
alkisg: Thank you for that
09:06
<alkisg>
:)
09:06
<sd34>
indeed!
09:06
<alkisg>
We'll try to do the same for another solution we have here, called "sch-scripts",
09:06
<Hyperbyte>
oh hi!
09:06
Has alkisg been talking about me again behind my back?
09:06
<sd34>
hi Hyperbyte :)
09:07
<alkisg>
that makes the whole ltsp-pnp, updating chroot etc, adding users, students, classes etc gui-driven
09:07
!hyperbyte
09:07
<ltsp`>
hyperbyte: We all thank our super duper webadmin for his contributions... er, also, reminder: make the irclogs.ltsp.org banner scrollable to save screen estate for mobile phones :D
09:07
<alkisg>
Haha sorry
09:07
That needs to be updated :P
09:07
<Hyperbyte>
!alkisg
09:07
<ltsp`>
alkisg: The LTSP oracle. Our beacon of hope in the world of LTSP. With the guidance of this divine emperor, we shall prevail.
09:07
<sd34>
I have to agree
09:07
<Hyperbyte>
While you guys are talking about hardware
09:08
<Fenuks>
By the way, you do localizations all by yourself or use something like Transifex?
09:08
<Hyperbyte>
Can I just mention my server's hardware specs?
09:08
<alkisg>
Fenuks: https://translations.launchpad.net/epoptes/
09:08
Hyperbyte: no, we don't need a inferiority complex
09:08
:D
09:08
<sd34>
lol
09:08
<Hyperbyte>
Well close your eyes then
09:09
Dual 8-core AMD Opteron Processor 6328, 64 GB RAM, 4x 600GB SAS disks RAID
09:09
:-D
09:09
<Fenuks>
Raid10?
09:09
<Hyperbyte>
Mirror, actually.
09:09
<alkisg>
Fenuks: translations in launchpad are completely automatic, epoptes was translated in 35+ languages without us developers doing anything at all, except for the initial setup... :)
09:10
<Hyperbyte>
Two mirrors. :)
09:10
<Fenuks>
4 disk mirror?
09:10
separate?
09:10
<Hyperbyte>
Yeah... 1200 GB storage.
09:10
<alkisg>
Hyperbyte: i'd love to see how many full-screen youtube thin clients that supports...
09:10
<Fenuks>
why not 10 then?
09:11
<Hyperbyte>
alkisg, it has 3 Gbit cards trunked to local switch. :)
09:11
<alkisg>
http://www.cpubenchmark.net/cpu.php?cpu=AMD+Opteron+6328&id=1982&cpuCount=2 ==> 11933 cpu mark
09:11
<Hyperbyte>
Fenuks, doesn't matter much does it?
09:11
<alkisg>
Here most of the schools have a server with a mark of about 1500 :(
09:11
<Fenuks>
alkisg: I'll need to check it out then, I prefer to use en_US locale everywhere
09:15
<Hyperbyte>
alkisg, to be fair though... I run this entire company on one server at the moment. Runs a bunch of virtualized servers (including thin client server) and application servers.
09:16
This is a ~5000 euro server, but since we're using it to the max it's really worth it's money.
09:17
For just LTSP this kind of hardware would be immensely overkill for us.
09:19
One of the benefits of virtualization for me, much higher budget per server. :)
09:20
<sd34>
alkisg I can't find gnome-fallback, is that a distribution or a desktop environment? By the way I found out about LXLE, what do you think about it?
09:21Grembler has joined IRC (Grembler!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
09:23
<alkisg>
desktop environment, available at the software center, lxde == lubuntu that we were talking about above
09:25bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
09:39
<Hyperbyte>
It's called gnome-session-fallback
09:42alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
10:18workingcats has joined IRC (workingcats!~workingca@212.122.48.77)
10:42freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
10:43bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard)
11:00q2dg has joined IRC (q2dg!5f15c1fd@gateway/web/freenode/ip.95.21.193.253)
11:01
<q2dg>
Hello. Sorry for being so heavy, but...are there somebody who knows which is the state of Ltsp in Fedora? Thanks
11:08
<Hyperbyte>
q2dg, I believe Enslaver has made LTSP compatible with Fedora 19
11:08
Not sure yet if that's released or not. With previous versions it was compatible fine I believe.
11:08alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
11:09
<q2dg>
Ok, thanks a lot
11:29Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
11:35Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 268 seconds)
11:57david007co2 has joined IRC (david007co2!~androirc@186.28.209.238)
12:04Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212)
12:16willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
12:33willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Ping timeout: 245 seconds)
12:58david007co2 has left IRC (david007co2!~androirc@186.28.209.238, Ping timeout: 268 seconds)
12:59Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 245 seconds)
13:27david007co2 has joined IRC (david007co2!~androirc@190.24.160.36)
13:32alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out)
13:36q2dg has left IRC (q2dg!5f15c1fd@gateway/web/freenode/ip.95.21.193.253, Quit: Page closed)
13:43dsugar100 has joined IRC (dsugar100!~dsugar@columbia.tresys.com)
13:43
<bennabiy>
Hyperbyte: Do you run your LTSP server as a VM?
13:43
What virt tech are you using on that server?
13:56
<Hyperbyte>
bennabiy, yes, it's a thin client server, running as virtual machine... don't notice any difference between non virtualized setup... In fact, I find it performing a bit faster, but that's probably because it doesn't have to go across network to get files or internet access
13:57
Using qemu-kvm on Centos 6.4
13:57
LTSP server is Ubuntu 12.04.3
14:11alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
14:16sd34 has left IRC (sd34!4f281bd5@gateway/web/freenode/ip.79.40.27.213, Quit: Page closed)
14:19
<bennabiy>
I have only had a little experience running Xen, and VMWare and VirtualBox
14:19
<Hyperbyte>
How did that turn out?
14:19
<bennabiy>
I mean, little experience on Xen, lots on vmware and virtualbox
14:20
vmware and virtualbox work fine, but I have never run the lab from virt for a long period of time, or from a headless node
14:20
It is an idea I have been toying with here though
14:21
What do you mean it doesnt need to go across the network to get files or internet access?
14:21
Your file server is another VM, I am guessing... but I am not understanding about the internet
14:25brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-mcqgrdklyjnzdojd, Quit: Leaving.)
14:26brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-ctbuaunxvtoyqsve)
14:48dsugar100 has left IRC (dsugar100!~dsugar@columbia.tresys.com, Remote host closed the connection)
14:54brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-ctbuaunxvtoyqsve, Quit: Leaving.)
15:09dsugar100 has joined IRC (dsugar100!~dsugar@columbia.tresys.com)
15:25vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
15:38gbit has joined IRC (gbit!~chatzilla@unaffiliated/gbit)
15:39
<gbit>
Hello, how can I edit default language on Ltsp login screen?
15:39
tried FORCE_LDM_LANGUAGE="pt_BR.UTF-8" with no luck
15:41mikkel has left IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net, Quit: Leaving)
16:02PhoenixSTF has joined IRC (PhoenixSTF!~rudi@bl9-43-215.dsl.telepac.pt)
16:04willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
16:12willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.)
16:26Jason_ has joined IRC (Jason_!18f0cb5a@gateway/web/freenode/ip.24.240.203.90)
16:26
<Jason_>
I have some general questions about LTSP and looking for help
16:28willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
16:33
<cliebow>
Jason_:ask away..i cant help much but someone might chime in
16:34Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
16:35
<Jason_>
Thank you. Main question: Can I run Windows 7 directly on top of LTSP or will I also need to setup some type of virtual environment to accomplish this?
16:35Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds)
16:37
<other_other_joe>
your windows host box will need to run on it's own server install
16:37
be it vm or metal
16:38
your ltsp box(tftp,dhcp,etc) will handle all an initial pxe boot and authentication then direct the client to the windows server install via rdesktop
16:38
<Jason_>
understood, thank you. Would you recommend against running the LTSP and the Windows host on the same server?
16:39
<other_other_joe>
if you've got enough resources to run both virtually, I don't see why not. Frankly though, I've not tried
16:40willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Ping timeout: 245 seconds)
16:41
<Jason_>
thank you again, last question -- does anyone have any recommended reading resources for using LTPS to connect to a Windows host
16:41PhoenixSTF has left IRC (PhoenixSTF!~rudi@bl9-43-215.dsl.telepac.pt, Quit: Leaving)
16:42
<other_other_joe>
!manual
16:42
<ltsp`>
manual: http://sourceforge.net/projects/ltsp/files/Docs-Admin-Guide/LTSPManual.pdf/download
16:42
<other_other_joe>
there's a section on it in there
16:42
though it's not terribly comprehensive, it should give you a good idea of how to handle yourself
16:43
<Jason_>
thanks again
16:43
<other_other_joe>
you bet
16:43
good luck, sir
16:44Jason_ has left IRC (Jason_!18f0cb5a@gateway/web/freenode/ip.24.240.203.90, Quit: Page closed)
17:06
<vagrantc>
gbit: you want the login manager localized, or the session?
17:07
gbit: LDM_LANGUAGE sets the sessions locale, LANG sets the display manager's locale
17:07
bennabiy: did you get the patches for mint into ltsp-trunk?
17:08alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 268 seconds)
17:08
<vagrantc>
bennabiy: i'm hoping to upload to debian soon, and it'd be nice to have the fixes you need in, as ubuntu may eventually merge those changes too
17:11
<gbit>
vagrantc: I want the login session, the first screen when you entry user/pass
17:17david007co2 has left IRC (david007co2!~androirc@190.24.160.36, Ping timeout: 246 seconds)
17:27
<vagrantc>
gbit: set LANGin lts.conf
17:27willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
17:28
<vagrantc>
gbit: i.e. LANG="pt_BR.UTF-8" in lts.conf
17:30
<bennabiy>
vagrantc: I can work on them this afternoon or tomorrow
17:30
I have been wrestling with LDAP
17:31
<vagrantc>
bennabiy: i forget what the status was...
17:31
<bennabiy>
Basically, I just need to enable it to remember and check the variables for either ubuntu or mint chroot
17:31
and since I lost alksig's patch, I need to think of how to do it
17:31
lunch time now, so I will be back
17:32
Are you going to be around this afternoon?
17:32
<vagrantc>
define afternoon :p
17:33
<bennabiy>
well, I am 3 hours ahead of you...
17:33
<vagrantc>
i'll be around for maybe 4-6 hours more
17:33
<bennabiy>
ok
17:33
that works
17:33
I will be about 45 minutes or so... gotta bring lunch to my family (my girls are ill)
17:34
<vagrantc>
bennabiy: that'd place you somewhere in the middle of the atlantic :p
17:34
<bennabiy>
are you still in Maine?
17:34* vagrantc nods
17:34
<bennabiy>
how long is BTS?
17:34
or are you just hanging out?
17:35
<vagrantc>
yeah hanging out with a freind who lives here
17:35
<bennabiy>
nice.
17:35
<vagrantc>
and getting done the stuff i had hoped to get done during the bts :)
17:35david007co2 has joined IRC (david007co2!~androirc@186.28.191.73)
17:35
<bennabiy>
that is usually how it is
17:35
we do little conferences like that as well for our group, and we are either totally productive, or totally distracted during them :)
17:36
so usually for me when everyone goes to bed is my most productive time
17:36
anyway, gotta reboot
17:36bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Quit: http://www.twelvetribes.org)
17:40
<gbit>
vagrantc: it does not work, still in english. I dont care but users do
17:41
<vagrantc>
are the locales enabled in the chroot?
17:41
!distro
17:41
<ltsp`>
I do not know about 'distro', but I do know about these similar topics: 'bestltspdistro'
17:41
<ogra_>
me would have used LC_ALL instead of LANG
17:41
<vagrantc>
!rlease
17:41
<ltsp`>
I do not know about 'rlease', but I do know about these similar topics: 'release'
17:42
<vagrantc>
could try LC_ALL, but i know LDM respected LANG in the past
17:48bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
17:49
<vagrantc>
and LC_ALL basically does some magic that sets LANG, no?
17:50
we really need to do automated tranlations in a separate branch
17:51
makes bzr log almost unuseable
17:54
<gbit>
does not work with LC_LANG either
17:56brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-nfipmdyybygtldgd)
17:56
<vagrantc>
gbit: did you make sure the locale is available in the chroot?
17:57
<gbit>
vagrantc: No where should I look?
17:57
<vagrantc>
what distro?
17:57
<gbit>
Debian
17:58
<vagrantc>
grep -v ^'#' /etc/locale.gen
17:58
and /opt/ltsp/*/etc/locale.gen
17:58
<gbit>
nice
18:04
But still in english
18:04
I leave only pt_BR on locale.gen
18:09
<vagrantc>
was it present?
18:10
you need to re-run it if it wasn't generated
18:10* vagrantc also wonders if the pt_BR translation is up to date
18:11
<gbit>
it was commented
18:11
I rebooted the remote machine
18:11vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
18:11
<vagrantc>
on the server and in the chroot?
18:11
<gbit>
only on the chroot
18:11
<vagrantc>
gbit: you need to do more...
18:12
gbit: do the users want it enabled on the server? or just at the login screen?
18:12
<gbit>
do I need to rebuild the ltsp?
18:13
The users have Portuguese on Gnome session, no problem, I just like to have the login screen in PT_BR too
18:13
<vagrantc>
you need too generate the locales, at the very least...
18:13
<gbit>
ok I will find out how to do that
18:13yanu has left IRC (yanu!~yanu@lugwv/member/yanu, Read error: Connection reset by peer)
18:13
<gbit>
thank you
18:13
<vagrantc>
gbit: so it's configured correctly on the server?
18:13
<gbit>
vagrantc: yes it is
18:14yanu has joined IRC (yanu!~yanu@178-117-230-250.access.telenet.be)
18:14yanu has joined IRC (yanu!~yanu@lugwv/member/yanu)
18:14
<vagrantc>
gbit: ltsp-chroot locale-gen
18:14
gbit: did you build the ltsp environment on another server?
18:14
<gbit>
no
18:15
pt_BR.ISO-8859-1... done
18:15
pt_BR.UTF-8... done
18:15
<vagrantc>
it should have picked up the settings from the server when you built it...
18:15
disable the ISO one...
18:15
why it leaves non-utf8 locales in this day and age....
18:16
the server is debian?
18:16
<gbit>
yes
18:18
<vagrantc>
and you built the ltsp chroot after the locales were set on the server?
18:18
<gbit>
I dont think so
18:18
I preffer english, so I installed debian in english
18:19
<vagrantc>
ah, that would explain it, then
18:19
<gbit>
I guess I should installed locale pt_br before build ltsp
18:19
<vagrantc>
gbit: yeah
18:19david007co2 has left IRC (david007co2!~androirc@186.28.191.73, Ping timeout: 246 seconds)
18:19
<gbit>
how risky is to rebuild ltsp?
18:20
I got it in prodution already
18:20
<vagrantc>
gbit: if you're using NFS, it should work now without any further action
18:20
if using NBD, you'd have to rebuild the image
18:21
<gbit>
I pretty sure I'm in NFS, cuz they all pxe
18:23
<vagrantc>
both NFS and NBD use pxe...
18:23
gbit: reboot and see if it works
18:23
gbit: default is NFS
18:23
<gbit>
It did not. I guess I need to study ltsp more
18:24
I'm old thinstation user.
18:24
<vagrantc>
do you have a file in /opt/ltsp/images ?
18:24
then it might have gotten set up for NBD
18:24
<gbit>
I have /opt/ltsp/i386/ then chroot
18:24
yes they do
18:24
<vagrantc>
then chroot?
18:25
<gbit>
I mean the linux
18:25
<vagrantc>
if it's set up for nbd, you'll have to run ltsp-update-image, but this may break running thinclients
18:25
??
18:25
<gbit>
ok
18:25
I guess they will live with english login screen
18:26* vagrantc isn't at all sure how it's st up
18:26
<vagrantc>
for gbit
18:27
it might also not be reading the lts.conf file you thiink it is... which file are you editing?
18:27
<gbit>
I'm editing /opt/ltsp/i386/etc/lts.conf
18:29
<vagrantc>
that would wor for nfs... is there also one in /srv/tftpboot/ltsp/... or /var/lib/tftpboot/ltsp... ?
18:29
<gbit>
let me check
18:30
<vagrantc>
i would add SCREEN_02=shell and see if it drops you to a shell instead of ldm
18:30
debian wheezy, i hope?
18:30freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
18:30
<gbit>
it has but there are the boot files
18:30
yes debian 7 x64
18:31
<vagrantc>
it will use the one in one of the tftp dirs first
18:32
<gbit>
it is reading lts.conf because I set up a specific resolution for my hyper-v network machine and it works
18:34david007co2 has joined IRC (david007co2!~androirc@190.24.160.36)
18:35
<vagrantc>
ok, if you're sure
18:36
<bennabiy>
vagrantc: seen alkisg today?
18:37
<vagrantc>
!seen alkisg
18:37
<ltsp`>
alkisg was last seen in #ltsp 9 hours, 13 minutes, and 48 seconds ago: <alkisg> desktop environment, available at the software center, lxde == lubuntu that we were talking about above
18:37
<bennabiy>
I just want to make sure that I am hitting the needed configs.
18:39
Currently, we need A) to build mint chroot on mint server ( I am not trying to build older chroots on newer server, as it is not very supportable) B) ubuntu chroot on mint server(of any debootstrappable version) and C) mint chroot on ubuntu / debian server
18:39
<vagrantc>
gbit: you're definitely using nfs, then
18:39
<gbit>
vagrantc: great
18:39
<bennabiy>
vagrantc: does that sound right?
18:40
<vagrantc>
bennabiy: should be able to specify older versions with a simple commandline flag, no?
18:40
<bennabiy>
yes, but limited to package availability
18:40
<vagrantc>
ah, right
18:41
<bennabiy>
basically any dist which ubuntu still supports back to Nadia (mint 14)
18:41
<vagrantc>
well, you still will be limited until it gets included in mint/ubuntu...
18:41
<bennabiy>
yes
18:41
which is why I have a PPA
18:41
!LinuxMint
18:41
<ltsp`>
LinuxMint: LinuxMint: Now Available: https://launchpad.net/~bennabiy/+archive/testing Developmental Branch for Mint support (Does not support LMDE yet, sorry) The client build process might be a bit unstable. To build a working Mint chroot, as root, type: MINT_DIST=<codename> ltsp-build-client --arch <arch> --accept-unsigned-packages
18:41
<bennabiy>
I am updating this as things change
18:42
<vagrantc>
all/most changes needed were server side, not client side?
18:42
<bennabiy>
as far as code?
18:42workingcats has left IRC (workingcats!~workingca@212.122.48.77, Quit: Leaving)
18:42
<bennabiy>
none client side as far as I can remember
18:42
all within build-client-image
18:42
plugins
18:43
<vagrantc>
so it would support all the older dists...
18:43
<bennabiy>
yes
18:43
well, back to mint 14
18:43
if you specify --dist and --mint-dist then back to 13
18:44
most people would not be worried about building older mint chroots
18:45
<vagrantc>
sure
18:46
by default, install the same version as on the server
18:46
<bennabiy>
yes
18:47
which most people would do anyway
18:48
<vagrantc>
so, is our merge proposal from september still valid?
18:48
<bennabiy>
I think the A and C can be solved by the same flag, if [ -n "$MINT_DIST" ]
18:48
no, I will cancel it
18:48
It was a patch fix but not the end result
18:49
<vagrantc>
is it worth applying anyways, even though it's imperfect?
18:49
<bennabiy>
link me?
18:49
<vagrantc>
i.e. does it work better?
18:51
the no-check-gpg is bad news...
18:51alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
18:51* vagrantc waves to alkisg
18:52
<alkisg>
Hi vagrantc, hi all
18:52Grembler has left IRC (Grembler!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave)
18:52
<bennabiy>
How can I get it to load mint keys before pulling packages?
18:52
<vagrantc>
bennabiy was trying to get the mint patches ready
18:53
bennabiy: for debootstrap, it should use the ubuntu keyring
18:53
<bennabiy>
yes, but then when it pulls the early packages, it pulls some from mint
18:53
<vagrantc>
unless it's lmde, then it should use debian
18:53
<bennabiy>
no, they have their own debian repo
18:54
<vagrantc>
bennabiy: so you need to add the mint keyring
18:54
<bennabiy>
they do not use debian keys
18:54
<vagrantc>
oh
18:54
even crazier
18:54
<alkisg>
gbit: one easy way to see if your chroot locale is ok: sudo chroot /opt/ltsp/i386 gettext -d ldm 'Password' ==> that should return the translated string
18:54
<bennabiy>
yes, which is why their code base for debian is a little stale compared to live debian
18:54
alkisg: did you see my 3 use cases listed above?
18:55
(repost) Currently, we need A) to build mint chroot on mint server ( I am not trying to build older chroots on newer server, as it is not very supportable) B) ubuntu chroot on mint server(of any debootstrappable version) and C) mint chroot on ubuntu / debian server
18:55
<vagrantc>
i daresay they're doing it wrong if their "more up to date" version of debian is behind debian stable
18:55
<alkisg>
bennabiy: a quick glance, yeah, but it will need a bit of time to re-sync my thoughts with the mint stuff so I tried to avoid that for now, I just got back from a long trip for an ltsp workshop... :)
18:56* bennabiy feels like the red-headed stepchild of the LTSP world...
18:56
<bennabiy>
;)
18:56
<alkisg>
Hehe, are red-headed childs something bad?! :)
18:57
<bennabiy>
nope!
18:57
<gbit>
alkisg: yes it is!
18:58
<bennabiy>
vagrantc: that branch which has the merge request to ltsp-LM is the branch I am working on
18:58
<alkisg>
gbit: which debian version is that? wheezy?
18:58
<gbit>
wheezy
18:58
<bennabiy>
let me just update a few things, and I will push my updates
18:58
then you can see where it is at
18:59
<alkisg>
!screen_08 | echo gbit:
18:59
<ltsp`>
gbit: screen_08: To get a root shell on a Debian thin client, put SCREEN_07=ldm, SCREEN_08=shell and SCREEN_DEFAULT=07 to lts.conf.
18:59
<alkisg>
From that screen 08, run getltscfg -a
18:59
And verify that LANG=your language
19:01
<gbit>
alkisg: moment pleasy
19:01
*please
19:02adrianorg has left IRC (adrianorg!~adrianorg@177.134.56.54, Ping timeout: 245 seconds)
19:03
<bennabiy>
alkisg: is there a way I can tell the debootstrap to grab the key for mint, before trying to pull packages, so that it will not need --accept-unsigned-packages?
19:03
<vagrantc>
bennabiy: you debootstrap from ubuntu, though...
19:04adrianorg has joined IRC (adrianorg!~adrianorg@177.134.60.230)
19:04
<vagrantc>
bennabiy: only reason you need --accept-unsignedd... is because you not using either ubuntu or mint
19:04
<alkisg>
Why would you need that? Mint only gets pulled after the debootstrap phase, since there's no bootstrap entry for mint, right?
19:05
<bennabiy>
I am not saying it right...
19:06
basically, when it tries to pull the linuxmint-keyring it errors for not having signed package
19:06
<gbit>
alkisg: it is set right
19:06
<alkisg>
gbit: can you pastebin your lts.conf?
19:07
<gbit>
sure
19:07
<alkisg>
bennabiy: is linuxmint-keyring pulled in EARLY_PACKAGES?
19:07
<vagrantc>
bennabiy: you 'll need to add the key after debootstrap and before installing packages...
19:07
<bennabiy>
yes
19:08
EARLY_PACKAGES= ltsp-client linuxmint-keyring
19:08
<gbit>
alkisg: http://pastebin.com/xEsR1rAJ
19:08
<alkisg>
There's some support in ltsp for manually providing keys, you could use that
19:08
<bennabiy>
What variable do I set?
19:08
I can do that in the configuration
19:09
<vagrantc>
APT_KEYS
19:09
be sure not to override the commandline option, though
19:09
<bennabiy>
if I manually set mint key, it will not override the default ubuntu one, right?
19:09
<alkisg>
gbit: that XKBLAYOUT entry doesn't seem right, but other than that, the rest seem ok... try with LDM_SESSION=xterm, to get a terminal after login, and there run the gettext command
19:10
<vagrantc>
bennabiy: the --apt-keys option adds extra keys
19:11
bennabiy: by default, it will already have the ubuntu kes
19:12
<bennabiy>
vagrantc: so if I do a APT_KEYS=${APT_KEYS:-"..."}
19:13
<alkisg>
ah sorry linuxmint-keyring's purpose is to add the key... so you don't even need it if you add it manually
19:13
<gbit>
alkisg: runned gettext, i got an error in Brazilian potuguese ( witch is right )
19:13
<alkisg>
Maybe you could pull that one specifically with --accept-unsigned-packages...
19:14
gbit: gettext -d ldm Password
19:14
That should say "password" in Portugese
19:14
<bennabiy>
alkisg: what phase should I do that?
19:14
<vagrantc>
you should still install the eyring packages for updates
19:14
<bennabiy>
vagrantc: yes
19:14
<gbit>
alkisg: "Password" I think you found it
19:15khildin has left IRC (khildin!~khildin@ip-213-49-84-217.dsl.scarlet.be, Remote host closed the connection)
19:15
<gbit>
is on english
19:15
<vagrantc>
bennabiy: linuxmint-keys should dump files in /usr/share/keyrings that you would add to the APT_KEYS var
19:15* alkisg was thinking about a script that runs before early_packages, which runs apt-get --accept-unsigned install $UNSIGNED_PACKAGES... that would work for other similar cases too
19:16
<bennabiy>
ahh, good thinking alkisg
19:16
<vagrantc>
alkisg: that would be an option for ad-hoc hacks, but not appropriate for a distro
19:17
<bennabiy>
according to you all, mint = ad-hoc hack...
19:17
;)
19:17
<alkisg>
vagrantc: I think ubuntu variants use a lot of those *keyring packages... e.g. medibuntu too
19:17* vagrantc nods
19:17
<bennabiy>
medibuntu is no more
19:17
<vagrantc>
alkisg: external repositories, or internal?
19:18
<alkisg>
I think their keyring is in ubuntu's universe, while the repository is external
19:18
<vagrantc>
alkisg: i think it's cleaner to add the keyring from a file than blindly download it off the internet
19:18
<bennabiy>
what about just a $KEYRING_PACKAGE
19:18
<alkisg>
vagrantc: the purpose of the package is to add a keyring
19:19
So supposedly if they change the keyring between versions, the code would still work
19:19
If we manually add the keyring, there's no reason to install the package
19:20
Hmm nope
19:20
Wrong logic
19:20
medibuntu-keyring is in universe
19:21
So one can install that in EARLY_PACKAGES with no problems,
19:21
while linuxmint-keyring isn't in universe
19:21awilliam1 has joined IRC (awilliam1!~awilliams@unaffiliated/mistik1)
19:21* vagrantc nods
19:21
<bennabiy>
It is from the mint server
19:21
<alkisg>
So I think it would be saner if one bugged the mint developers to put it in universe
19:21
So as to make it easier to install mint packages from an ubuntu system or chroot
19:21
<vagrantc>
alkisg: the purpose of the package is to ensure a maintained keyring
19:22awilliams has left IRC (awilliams!~awilliams@unaffiliated/mistik1, Ping timeout: 245 seconds)
19:22awilliam1 is now known as awilliams
19:22
<vagrantc>
typically keyring updates will happen long before the keyring is put into use
19:22
at least, if it's done well
19:22
<bennabiy>
vagrantc: I agree. We would still want to install the mint keyring
19:23
<vagrantc>
and yes, getting the keyring into ubuntu/debian would be good
19:23
<bennabiy>
i submitted the request
19:24
<vagrantc>
bennabiy: does lmde use a different keyring entirely?
19:26* vagrantc wonders if it's worth uploading to debian rather than ubuntu
19:28* alkisg notes that even with the keyrings in debian, one cannot install mint packages in EARLY_PACKAGES directly, he would need an apt-get update inbetween
19:28
<bennabiy>
yes
19:28
<alkisg>
But the code would be a lot simpler and more maintainable
19:28
<bennabiy>
Actually, I think LMDE might use the same keyring as mint
19:30
I am asking
19:30
<vagrantc>
i think apt-get update is run muliple times...
19:30
<bennabiy>
yes
19:31
<alkisg>
EARLY_PACKAGES="mint-keyring mint-desktop" ==> that wouldn't work
19:31
<vagrantc>
might make sense to have --keyring-packages that runs before early-packages and runs apt-get update after
19:31
<alkisg>
VERY_EARLY_PACKAGES="mint-keyring"; EARLY_PACKAGES="mint-desktop" => that would
19:31
+1 for keyring-packages or something similar
19:31* vagrantc nods
19:31willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Textual IRC Client: http://www.textualapp.com/)
19:32
<bennabiy>
actually, the rest of mint gets added in LATE_PACKAGES
19:32
except for fat client which I am not supporting yet
19:32* vagrantc notes that jetpipe is still started from init-ltsp:d upstream
19:33
<alkisg>
Ah, btw, it would be nice to have something like RCFILE_xx for init-ltsp.d, to run commands at that phase,
19:34
<vagrantc>
yay. built ltsp packages for 5.4.6~
19:34
<alkisg>
and, to have a hook for things to start when the services start, e.g. called by ltsp-client-core
19:34
<bennabiy>
how do I find out what the current key is, in a way that can be added through commandline option?
19:34
<alkisg>
The jetpipe call could go there
19:34
dpkg -L linuxmint-keyring
19:34
Search for the .asc file there
19:35freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
19:35
<bennabiy>
alkisg: no .asc file
19:35
gpg file
19:35
<alkisg>
An alternative approach would be to have an UNSIGNED_PACKAGES variable, which would be run after EARLY_PACKAGES and before LATE_PACKAGES
19:36
<bennabiy>
that would work.
19:36
<vagrantc>
badly
19:36alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
19:36
<bennabiy>
vagrantc: would I hurt myself by pulling and syncing up the latest changes to my branch?
19:36* alkisg could use that too for his greek schools repository, if he was using ltsp-build-client, which he doesn't... :)
19:36
<vagrantc>
given that you mint server already has the correct keyrings installed...
19:37
<bennabiy>
vagrantc: but ubuntu does not
19:37
nor debian
19:37
<vagrantc>
bennabiy: but you have the files on your mint server
19:37
<bennabiy>
if it were just for mint to build mint, I would have had it done already
19:37
<alkisg>
vagrantc: suppose you want to build a mint chroot from a debian/ubuntu system
19:37
<vagrantc>
bennabiy: focus on mint on mint first, everything else is extra
19:37
<bennabiy>
can you both come to one mind?
19:37
<alkisg>
You don't have the keys there
19:38
<vagrantc>
alkisg: then you'd best know what you're doing :p
19:38
<alkisg>
Unless you include the keys with ltsp, which seems a little silly
19:38
<bennabiy>
vagrantc: I had mint on mint working fine, and then alkisg popped in that bomb to get it able to work the other way around
19:39
<vagrantc>
if the users doesn't provide keys for the archive they're using, it should fail by default
19:39* alkisg favors the "putting mint-keyring into debian" first, and the "UNSIGNED_PACKAGES" solution second...
19:39
<bennabiy>
I doubt they are going to put it in, but I suggested it
19:39
<alkisg>
Supposedly mint support wouldn't require users to pull they keys themselves..
19:39
<vagrantc>
and on mint, it doesn't
19:39
alkisg: building ubuntu on debian has the same issue
19:40
i don't think that requires special-casing
19:40
<bennabiy>
so can I just make some code and let you two "discuss" how many ways I did it wrong?
19:41
<alkisg>
vagrantc: so how do you build an ubuntu chroot in debian? You manually pull the keys? Wouldn't UNSIGNED_PACKAGES help in that case?
19:41
<vagrantc>
i think it's reasonable to assume if you'e building a foreign distro you have extra hoops to jump through
19:41
alkisg: i was able the verify the keys manually, rather than blindly trusting
19:42
<bennabiy>
alkisg: Just because unsigned packages is available does not mean everyone is going to use it. It just allows for the special cases to be able to use if needed
19:42Andymeows has joined IRC (Andymeows!~Andymeows@173-11-52-41-Minnesota.hfc.comcastbusiness.net)
19:42* vagrantc things foreign distro supoort is a feature to be added later
19:42
<vagrantc>
thinks
19:42
<bennabiy>
I do not see how it would hurt to have it, and state use at your own risk
19:43
<vagrantc>
get it working natively first
19:43
<bennabiy>
ok, brb
19:43
<alkisg>
Meh, http://packages.debian.org/ubuntu-keyring => nothing
19:43
So there's not much point in putting mint-keyring there
19:43* vagrantc nods
19:46
<vagrantc>
might be worth an rfp request
19:47
debootstrap supports ubuntu, but wthot a keyring...
19:47
well, it tries to find the keyring and fails if you don't have it
19:49
<alkisg>
It would add the keyring to the server first, though...
19:49
<vagrantc>
ah, you would want a modified version
19:49
<alkisg>
But ok that's not unreasonable
19:49
<vagrantc>
that just ships the keyring file
19:50
or optionally adds it if configured to do so
19:50kev_j has joined IRC (kev_j!~Kevin@web.ta-realty.com)
19:52
<bennabiy>
hmm. I could just wget the .deb before any apt-get
19:53* alkisg still prefers the UNSIGNED_PACKAGES approach with some large warning in CAPS, and of course people that don't want to use that, just wouldn't. They'd manually add the keyring etc.
19:54
<vagrantc>
bennabiy: that doesn't really fix the problem
19:54
a distro shouldn't rely on outside keys if it can get away with it
19:54
<kev_j>
Hey all, I have a problematic employee, and have epoptes... is there an easy(-ish) way to record the vnc sessions?
19:56
I am searching for answers on that, but I don't know how well a regular vnc recording prog would work with epoptes.
19:57
<alkisg>
mint on mint shouldn't require UNSIGNED_PACKAGES. sure, it could just copy the server key
19:57
but mint on <anything-else>, would be simpler with UNSIGNED_PACKAGES
19:57
<vagrantc>
alkisg: ok, good. :)
19:57
<bennabiy>
mint on mint would be fine without unsigned
19:58
I am trying to remember why mint needs --without-gpg on the debootstrap
19:58
<vagrantc>
i would rather see mint sport implementd without tying it up with essentially unrelated features
19:59
the unsigned-packages ida is ok by me, i just don't think it's needed for mint support
19:59
<bennabiy>
vagrantc, alkisg: I am installing a fresh mint 15 VM to test our changes.
20:00
<vagrantc>
that seems like a searate branch to merge
20:03
<bennabiy>
yes
20:03
now we decided to do all the mint configuring in 001-set-mint-dist?
20:03
or something like that?
20:03
and leave 000-basic-configuration alone?
20:04
I think I was caught in the middle of doing it either way.
20:04
<vagrantc>
that sunds better, if doable
20:04
gotta be careful with no overriding defaults
20:05
or rather, commandline options
20:07
<alkisg>
sbalneav: me and vagrantc were thinking of an intermediate step for ltsp6, with (libpam_sshauth + ldm with pam support), are you around to discuss it a bit?
20:08* vagrantc thinks alkisg gets most of the credit
20:08
<vagrantc>
then ltsp7 would be ldm-less ? :)
20:08
<bennabiy>
side question, is there a way to do LDAP auth for ltsp?
20:09
<vagrantc>
bennabiy: nothing built-in
20:09
<bennabiy>
vagrantc: thank you
20:09
<vagrantc>
in theory future plans would make that easier
20:09
<alkisg>
Even ldm with pam support would make that easier...
20:09
<bennabiy>
yes
20:09
<vagrantc>
i.e. libpam-sshauth would be eplaceable with arbitrary pam modules
20:10
<alkisg>
sbalneav: so if you think that implementing pam support (or just local login with "expect") in LDM wouldn't take much time, it would make ltsp6 development not require a separate branch...
20:12
<bennabiy>
vagrantc: If someone specifies a mint distribution from commandline, I am going to override --dist flag because it will break the chroot build potentially if someone specifies --mint-dist olivia --dist hardy
20:13
because the mint dist is tied to the equal ubuntu dist
20:14
or --dist lenny --mint-dist olivia
20:14
although it would be interesting ..
20:14
ok, virtual server is booted, just going to install the basics.
20:17Phantomas1 is now known as Phantomas
20:17
<bennabiy>
does that sound fine?
20:19
<vagrantc>
bennabiy: i think it should error out rather than override
20:20
<bennabiy>
What is the appropriate error method?
20:20
<vagrantc>
when it detects a proble, spit out an error message and exit 1
20:21
<sbalneav>
alkisg: Make ldm use pam? Pretty much a complete rewrite.
20:21
<vagrantc>
would be even better to use stderr, but i don't think other hooks do
20:21
<alkisg>
sbalneav: what about local login with expect? Would that be much different from ssh expect?
20:22
<sbalneav>
So, instead of screen scraping an ssh login, screen scrape a /bin/login?
20:22
<ogra_>
lol
20:22
<alkisg>
Something like that, yeah, but no ssh_askpass available...
20:23
<ogra_>
how about using lightdm instead
20:23
<sbalneav>
Well, I guess my question is, what is it that something like lightdm is missing that ldm provides?
20:23
<alkisg>
ogra_: would need a rewrite of all the scripts and docs that use LDM* variables, like LDM_GUESTLOGIN, LDM_USERNAME etc
20:24
<vagrantc>
the proof of concept for lightdm is coming along, and i think it doesn't even require a separate ltsp brach yet
20:24
<ogra_>
alkisg, well, but that was the plan anyway, no ?
20:24
<vagrantc>
sbalneav: prelogin hooks
20:24
for those, each dm has it's own way, if any, to do that
20:24
<alkisg>
ogra_: yes but we don't have the development power to do that quickly, while with LDM + libpam_sshauth, we could do it progressively on the main branch
20:25
<sbalneav>
So, stuff where you know the username, but not the password yet?
20:25
<vagrantc>
and autologin features are implemented differently
20:25
sbalneav: xrandr settings, for example
20:25
<ogra_>
alkisg, so install aahd in the client rootfs ... and make LDM ssh -X localhost :P
20:25
*sshd
20:26
(no, i'm not serious)
20:26
<vagrantc>
sbalneav: stuff where the username is irrelevent
20:26
<alkisg>
:)
20:26
<sbalneav>
I can't remember, does lightdm start X, or does X start and then lightdm run?
20:26* sbalneav goes to look
20:27
<vagrantc>
hack into X itself? :)
20:27
<sbalneav>
Lightdm runs x.
20:27
<alkisg>
sbalneav: lightdm starts X
20:27
<ogra_>
sbalneav, do you know if there are plans to bring mate to debian or ubuntu ? (there is a thread on the ubuntu-devel-discuss list of some people that would like to build a mate ubuntu derivative ...
20:27
<sbalneav>
ogra_: Mate is currently winding it's way into debian :D
20:27
<ogra_>
yay, great
20:27
<alkisg>
Cooool
20:28* vagrantc would be very surprised if mate would be accepted into debian
20:28
<sbalneav>
Oh, and GTK3 support is being worked on right now.
20:28
<ogra_>
they want to do an official thing ... i think getting the packages in is their first hurdle
20:28
<vagrantc>
ah, so mate is getting some serious overhaul
20:28
<sbalneav>
anywho... OK, so could we not configure light dm like this:
20:28
vagrantc: oh, yeah.
20:29
<alkisg>
The future of thin clients looks bright again :)
20:29
<sbalneav>
have lightdm call a wrapper instead of X
20:29
<ogra_>
alkisg, was it dark with xfce or lxde ?
20:29
<sbalneav>
alkisg: Why do you think I went so gaga over Mate and threw my (massive girth) weight behind it? :D
20:30
<alkisg>
ogra_: yeah it was a few steps down from gnome-2
20:30
<sbalneav>
wrapper starts X, but also does prelogin calls.
20:30
<ogra_>
i thought they are on par nowadays
20:31
sbalneav, i think the greeter (starting X) and the ligin part of lightdm are distinct
20:31
<vagrantc>
sbalneav: we could divert X aside and inset our wrapper there
20:31
<ogra_>
*login
20:31
<pscheie>
vagrantc, why would you be surprised if mate were accepted into debian?
20:31* vagrantc wonders how mir and wayland will work
20:31
<ogra_>
vagrantc, with a specific greeter
20:31
<vagrantc>
pscheie: because it was seen as unmaintained fork of old code not long ago
20:31
<sbalneav>
ogra_: The big problem, at least for me, is this: I've got people with 8+ years of experience with Gnome2, who are change averse. ANYTHING new, regardless of whether it's the same, better, or worse functionality, will be met with an negative response.
20:32
It will simply be different.
20:32
<vagrantc>
sbalneav: just patch your users.
20:32
<sbalneav>
And different = bad.
20:32
vagrantc: Would that I could.
20:32
<bennabiy>
vagrantc and sbalneav: I thought mate was already in debian... I thought it was already accepted
20:32
<sbalneav>
bbias, workping.
20:33
<pscheie>
sbalneav, just offer them a magic feather and tell them it, combined with the new interface, will make them more powerful (productive), ala "Dumbo"
20:35
<alkisg>
vagrantc, sbalneav: do you think we can write a few things that we'll need to re-write in a dm-agnostic way before we ditch LDM, in e.g. http://sync.in/ltsp ?
20:35
For example, available session detection, LDM_USERNAME, XRANDR*, ....
20:35
So that we can better measure the work to be done before an LDM-less ltsp...
20:36
<ogra_>
you could do some ingenious upstart things ;)
20:36
it is awesome for such stuff
20:36
<alkisg>
dm-agnostic, but init-system specific? nice... :P
20:37* ogra_ hopes debian switches to upstart too ... i know it is high on the list as sysv replacement)
20:37
<ogra_>
though that wont help on other distros
20:38* vagrantc is long-ago bored with init system debates
20:38
<ogra_>
haha
20:39
i think even petter got bored over the years
20:39
<vagrantc>
when certain distros started trying to force it on other distros by overintegrating componets... gah.
20:39
<ogra_>
yeah
20:40
<alkisg>
vagrantc: btw, is it considered bad practice/for security to have a specific ssh user that returns server info? E.g. instead of ldminfod, to have an "ltsp" user, and when someone tries to login as that user, to just return the equivelant of ldminfod output, and exit? nx* do that too, don't they?
20:40
<ogra_>
well, lennart seems to get through with that ... in many places
20:40
<vagrantc>
alkisg: it's harder to set up properly as a package maintainer
20:41
<ogra_>
alkisg, i think thats relatively safe if you a) use key auth ... and b) use the returning script as the users shell
20:41
<vagrantc>
but yeah, what ogra_ said
20:41
<ogra_>
but yeah, might be packaging hell
20:41
heh
20:41
<vagrantc>
whereas there are scripts for such thing with inetd
20:42
at least on debian
20:42
<alkisg>
OK, a separate daemon is more flexible too, allows for the client to provide info as well
20:43
<vagrantc>
alkisg: your big ideas for lts.conf replacements seem to fit in here
20:43
<alkisg>
Yeah, a centralized daemon for all those things, ldminfod, lts.conf etc would be nice
20:44
<vagrantc>
and i had envisioned that redesign as part of ltsp6
20:45
<alkisg>
Did we have a wiki page with ideas for ltsp 6?
20:45* vagrantc notes that there are manpages built with help2man, but that're not run by default?
20:45
<vagrantc>
alkisg: not yet...
20:46* alkisg starts to write some stuff in http://sync.in/ltsp ... (javascript required ;))
20:47* vagrantc looks the other way
20:49
<alkisg>
Why do LDM_PRINTER_LIST, LDM_PRINTER_DEFAULT have "LDM" in front, instead of "LTSP"?
20:50
They're just setting an environment variable, right?
20:50
I.e. they could even be used in console, non-X logins, correct?
20:52
<bennabiy>
if I set a variable in the commandline, it would be remembered in the later stages, right?
20:56
<vagrantc>
bennabiy: depends on how you need it remembered
21:00
bennabiy: if you need it to be recognized by programs executed, you need to export the variable
21:04
alkisg: they could probably be changed as you suggest
21:04
<bennabiy>
no, just by the build-client script
21:04kev_j has left IRC (kev_j!~Kevin@web.ta-realty.com, Quit: Leaving)
21:05
<alkisg>
LOCALDEV (ltsp6):
21:05
If a local user login is done, udisks could automatically mount those...
21:05
LOCALDEV_DENY_CD etc would be implemented by policykit
21:06
LTSP_FATCLIENT (ltsp6):
21:06
Should be selected upon login, not on boot
21:06
LDM_USERNAME, LDM_PASSWORD, LDM_AUTOLOGIN:
21:06
DM-specific, we could write some lightdm.conf setting files etc
21:07
<bennabiy>
vagrantc or alkisg: the call on the commandline, does it actually set the variable e.g. --dist setting $option_dist_value or does that happen after the commandline phase and before config phase?
21:07
what I am hoping is that $option_dist_value will be set by the time commandline 001-set-mint-dist checks commandline options
21:08
<vagrantc>
bennabiy: option_FOO_value is set after the commandline phase is done
21:09
bennabiy: plugins should check option_FOO_value in the configure phase
21:09
<bennabiy>
is there a variable I can check in the commandline phase?
21:09
<vagrantc>
what do you mean by check?
21:09
<bennabiy>
say I want to know if someone manually entered --dist at the cli
21:10
is that possible?
21:10
without parsing the args right there?
21:10
<vagrantc>
you would check for that in configure
21:11
<bennabiy>
ok
21:11
<vagrantc>
don't forget setting values in ltsp-build-client.conf
21:11
<bennabiy>
I thought alkisg was suggesting remembering things in commandline
21:11
<vagrantc>
overriding values seems like a bad idea to me
21:11
<bennabiy>
I have all my variables checking for config file
21:12
<vagrantc>
alkisg did have some tricky scheme to do so, yes
21:12
your variables?
21:12vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 245 seconds)
21:12
<vagrantc>
and also specified via enviorontment variables
21:12
<bennabiy>
yes, which would be the same as builder variables, right?
21:13
I mean config
21:13
eg. DIST
21:13
<vagrantc>
those are the three ways a user can set values: commandline options, configuration file, and environment variables
21:14
<bennabiy>
configuration and environment are both going to be in the form of $DIST etc right? and commandline gets set in configure phase to those type of variables ?
21:14
am I understanding it properly?
21:14
<vagrantc>
that's how it's set up, yes
21:14
<bennabiy>
so, if I have a commandline, a config and an environmental variable, which is going to take precedence?
21:14
<vagrantc>
but DIST would be set from environment or configuration file before commandline
21:15
<bennabiy>
so commandline overrides, right?
21:15
<vagrantc>
depends on the code...
21:16* bennabiy raises an eyebrow
21:17
<bennabiy>
gah, I will just force mint to make a mint chroot... unless someones options force it to break
21:17
<vagrantc>
well, for --dist, commandline takes precedences
21:18
but all set settings in basic-configuration respect a value already set
21:19
<alkisg>
Do pam hooks have access to X?
21:19
<vagrantc>
load-configuration file loads values in configure phase... but earl in the process
21:20
so most commandline options should override it, although some might get run earlier... that seems like a bug.
21:22
the idea should be: built-in defaults, overridden by envirnment, overidden by config file, overridden by commandline
21:23
<bennabiy>
that is what I thought
21:23Lumiere has left IRC (Lumiere!~jstraw@unaffiliated/jstraw, Ping timeout: 245 seconds)
21:23
<vagrantc>
anything else should be a bug
21:23
<bennabiy>
so by configuration phase, I should be able to check $option_blah_value against something?
21:24
or if [ -z "$option_blah_value" ]; then
21:24
right?
21:24
<vagrantc>
heh. i guess there's ltsp-build-client.conf which is different than using --config foo.conf
21:25* bennabiy sighs
21:25
<vagrantc>
bennabiy: yeah, that tells you if it was specified by commandline only, though
21:25
not configuration fle, built-in default, environ ent, etc.
21:25
<bennabiy>
yes. the variables all have builtin respect for configuration or environment
21:26
I am more worried about someone wanting something at the commandline
21:29
<alkisg>
vagrantc: ok here's a quick copy paste of a first version (formatting lost): http://paste.debian.net/64174/
21:31
I think the roadmap to ltsp6 is too long to implement in a non-progressive way... so maybe libpam_sshauth + ldm with local login screen scraping could help there
21:34
<vagrantc>
alkisg: that seems like a good overview
21:34
<alkisg>
Or we could start working with all the *other* things first, and commit libpam_sshauth after a couple of years...
21:35
Like e.g. socat instead of jetpipe, ltsp configuration daemon...
21:35
<bennabiy>
I feel like I am getting close... but it will have to wait till tonight.
21:35
<vagrantc>
alkisg: i don't think the sshaut stuff is so far away...
21:35
<bennabiy>
I will commit my changes before I stop, and you can look over the merge request, and see if I am crazy
21:36
<alkisg>
vagrantc: the sshauth stuff is close, but it depends on a whole lot of things that aren't close
21:36
I.e. the no-ldm things
21:36
<vagrantc>
alkisg: the session selection stuff is largely mangling .desktop files...
21:38
<alkisg>
vagrantc: we need the ldminfod replacement to get the .desktop files from the server
21:38
There's no point in trying to create them via the current ldminfod output
21:39* vagrantc wouldn't say there's no point
21:40
<alkisg>
I mean, we'd add code to ldminfod to send more info, then parse it on the client, create the desktop files etc,
21:40
and when the ldminfod replacement is done, we'd throw away that code and just get the files from the server and use sed
21:40
<vagrantc>
we could create passable files as is
21:41
<alkisg>
no point ==> I mean about writing + throwing away code
21:42Lumiere has joined IRC (Lumiere!~jstraw@unaffiliated/jstraw)
21:42david007co2 has left IRC (david007co2!~androirc@190.24.160.36, Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
21:43
<alkisg>
Hmm AccountsService will be tricky
21:44
We'll need to get the /var/lib/AccountsService/_user_ file from the server, and possibly restart the accountsservice
21:50
Meh, and those files on the server are not writeable by the user
21:50
.dmrc ftw!
21:51
<stgraber>
or just disable user listing and ignore accountsservice entirely
21:51
<alkisg>
stgraber: it's not only user listing, it's default session + language too
21:51
<stgraber>
I think what we discussed at BTS was to provide a LTSP (default) session which would pick whatever's in the remote .dmrc
21:52
so if the user doesn't select some other session, it'll just go with whatever's in .dmrc and we'd update .dmrc as we currently do
21:52
<alkisg>
stgraber: so, disable the accountsservice on the client entirely? is lightdm ok with that?
21:52
<stgraber>
there's a lightdm setting to allow manual logins and another to hide the user list
21:52
that's how I usually configure my machines
21:53
greeter-show-manual-login=true
21:53
greeter-hide-users=true
21:53
<alkisg>
I type my username and password in lightdm. Even with the user list hidden, lightdm will query accountsservice with dbus, right?
21:54
It will see my default session + language from there (which won't exist on the client), and decide I want to use the chroot defaults
21:54
<stgraber>
sure but there'll be nothing to query, so it should be fine
21:54
<alkisg>
Then at that point we'll try to override the chroot defaults with the user's .dmrc?
21:54
Does lightdm provide a hook there?
21:56brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-nfipmdyybygtldgd, Quit: Leaving.)
21:56
<stgraber>
so from what I remember we said we'd have a 00ltsp Xsession.d script which would figure out whether the session is local (fat) or remote (thin), would check if it's the default session, parse the relevant .dmrc, save the .dmrc and then exec Xsession again with the right parameters (over ssh for thin, locally for fat)
21:56
<alkisg>
Also, some people might even have problems typing their password, if we don't tell lightdm about their keyboard setup...
21:57
<stgraber>
well, I'd expect the keyboard layout from lts.conf to still be respected as is the case under ldm, no difference there
21:57
<alkisg>
lightdm changes the keyboard layout
21:57
It doesn't respect the one set by X
21:57
(I've filed a few bug reports about it years ago... :()
21:58
<stgraber>
we just need to update whatever it uses for that, possibly /etc/default/keyboard and have that set to the value from lts.conf
21:58
<alkisg>
It reads it from accountsservice, which in turn has a bug and only reads the first entry of /etc/default/keyboard, ignoring the rest
21:58brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-owbktmeeyxpfyowh)
21:59
<stgraber>
ok, then maybe one of the *-script in lightdm.conf run sufficiently late that we can have those run a script that sets the keyboard and screen resolution from lts.conf
21:59
thinking of display-setup-script or greeter-setup-script
22:00
<alkisg>
With the user list disabled, that might work (lightdm changes the layout every time a user is selected, i don't know if it does that with the user list hidden too)
22:01
<bennabiy>
Ok, I am pushing my changes, although incomplete, so that you can see the thought I am taking
22:02* alkisg thinks we'll hit quite a few blockers when ditching ldm, so it might be a good idea to start with the rest of the ltsp6 ideas *first*....
22:02
<vagrantc>
alkisg: it seems quite plausible for them to co-exist
22:03
alkisg: i.e. ltsp5 with ldm and lightdm and libpam-sshauth all in the same chroot
22:03
<alkisg>
vagrantc: but where will our hooks be then? won't some of them be ran twice?
22:04
E.g. some ran both by pam and by ldm...
22:04
<vagrantc>
alkisg: we can incremtally add bits and pieces
22:06
alkisg: could even make shared bits into functions
22:07
and if necessary, check if they've already been run or something
22:08
<alkisg>
vagrantc: suppose we implement the new lts.conf/ldminfod replacement daemon... will that also support the LDM* variables and old-style ldminfod output?
22:08
(not directly related to what we were saying above)
22:12
stgraber, vagrantc, sbalneav: was it decided in BTS if a local user will always exist, even if localapps/fats aren't used, so that the ssh socket is owned by the user, pulseaudio is started from the user account, etc etc?
22:13
<bennabiy>
vagrantc and alkisg: pushed...
22:13yanu has left IRC (yanu!~yanu@lugwv/member/yanu, Read error: Connection reset by peer)
22:13
<bennabiy>
back in a few hours
22:13
<alkisg>
bennabiy: nice, bb :)
22:14
<vagrantc>
alkisg: it was not decided, but i'm thining that would be reasonable
22:14yanu has joined IRC (yanu!~yanu@lugwv/member/yanu)
22:14
<stgraber>
alkisg: I don't think we discussed this issue specifically, though since libpam-ssh + libnss-ssh do this basically for free without requiring the current edits in passwd, shadow and group, I think it'd be reasonable to do it by default
22:14* vagrantc notes that the group handleing doesn't work with libnss-extrausers
22:15
<vagrantc>
only gids/uids above 500 are treated as valid
22:15
<alkisg>
OK, that's one part that we can start even from now, in trunk
22:16
<vagrantc>
session selection wit ligtdm seems borked...
22:16
<alkisg>
ssh socket, no remoteappsd, user pulse....
22:16
ogra_: does replacing jetpipe with socat sound reasonable?
22:16
<stgraber>
vagrantc: so I remember we've gone with extrausers last year but I can't remember why we actually stuck with it instead of just fixing our own nss plugin
22:17
<vagrantc>
stgraber: probably just too much work
22:19
maybe ther's a way to tell extrausers to be less paranoid?
22:19
<stgraber>
could be. My hope was that we could do something along the lines of: libpam-ssh connects to server, creates socket (root owned), ... => libnss-ssh uses that socket to forward any request to the server (using getent on the server) => libpam-exec chowns the socket back to the right uid/gid => rest of the stack
22:19
<alkisg>
vagrantc: it's hardcoded, #define in .c code
22:19
(the 500 limit)
22:20
<vagrantc>
ah
22:20
<ogra_>
alkisg, dunno, try it
22:21
<alkisg>
Ah jetpipe is in python, I thought it was in .c
22:21
<vagrantc>
huh. for some reason 'ltsp-localapps xterm' works fine with ldm, but not with lightdm + sshauth
22:21
<ogra_>
i guess netcat would work :)
22:24
<stgraber>
getting it working for simple printers shouldn't be a problem with nc, but serial printers won't work
22:24
so I think we should stick to python
22:25
<alkisg>
there were bug report about instability
22:25
*reports
22:26
socat does have options for xon/xoff etc
22:26
and supports encrypted etc connections too, if we want them, needs less ram... anyway since jetpipe is not in .c I don't mind :)
22:27
<stgraber>
I'm not seeing any jetpipe bug open against jetpipe in Ubuntu or upstream, so I guess we must have fixed those
22:27
<alkisg>
stgraber: I think people reported them here in IRC for 12.04 a few times too
22:28
But anyways, np from me
22:28
<stgraber>
ah could be, I believe I fixed a bug with the daemoning code at some point after 12.04, that used to give us some trouble
22:28
(replaced by good old hand made daemonizing)
22:29
<alkisg>
I think the person that reported it had tried the & workaround, but anyway.
22:29
So, is everyone OK if I commit the change to always create the user locally in trunk? (although not very soon...)
22:29
<vagrantc>
the & workaround didn't work on debian
22:29
<alkisg>
....and then try the remoteappsd/pulse things?
22:29
<vagrantc>
alkisg: for ldm?
22:29
<alkisg>
Yup
22:30
<vagrantc>
should be doable
22:30
<stgraber>
yeah, the & was a bad idea, the current fork + exit code in jetpipe seems reliable though (as for some reason python-daemon wasn't...)
22:30
<vagrantc>
ltsp-localappsd could also run as the user, i think
22:30
stgraber: we shouldn't run daemons from init-ltsp.d anyways...
22:31
<alkisg>
Yeah we need a hook called by ltsp-client-core
22:31* vagrantc just patched it back inti ltsp-client init
22:32
<alkisg>
OK, so when I get some time to work on LTSP, I'll try the local user / pulse etc stuff. 'night all!
22:32alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
22:38GrembleBean has joined IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
22:43Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
23:07Andymeows has left IRC (Andymeows!~Andymeows@173-11-52-41-Minnesota.hfc.comcastbusiness.net, Ping timeout: 285 seconds)
23:58awilliams has left IRC (awilliams!~awilliams@unaffiliated/mistik1, Ping timeout: 240 seconds)