00:00 | leio has left IRC (leio!~leio@gentoo/developer/leio, Remote host closed the connection) | |
00:02 | leio has joined IRC (leio!~leio@gentoo/developer/leio) | |
00:03 | cliebow_ has left IRC (cliebow_!~cliebow@66.63.66.218, Quit: This computer has gone to sleep) | |
00:58 | ChadLepto has left IRC (ChadLepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net, *.net *.split) | |
00:59 | ChadLepto has joined IRC (ChadLepto!~chadlepto@c-71-237-229-76.hsd1.or.comcast.net) | |
01:30 | Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas) | |
01:31 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 240 seconds) | |
02:20 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
02:23 | leio has left IRC (leio!~leio@gentoo/developer/leio, Ping timeout: 245 seconds) | |
03:04 | leio has joined IRC (leio!~leio@gentoo/developer/leio) | |
03:05 | F-GT has left IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net, Quit: Leaving) | |
03:12 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
03:21 | david007co2 has left IRC (david007co2!~androirc@186.28.209.238, Read error: Connection reset by peer) | |
03:23 | Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas, Ping timeout: 240 seconds) | |
03:35 | david007co2 has joined IRC (david007co2!~androirc@186.28.209.238) | |
03:38 | F-GT has joined IRC (F-GT!~phantom@ppp59-167-136-109.static.internode.on.net) | |
04:13 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
05:03 | david007co2 has left IRC (david007co2!~androirc@186.28.209.238, Ping timeout: 252 seconds) | |
05:04 | Enslaver has left IRC (Enslaver!~Enslaver@fedora/Enslaver, Ping timeout: 272 seconds) | |
07:10 | Enslaver has joined IRC (Enslaver!~Enslaver@fedora/Enslaver) | |
07:20 | mikkel has joined IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net) | |
07:25 | mikkel has left IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net, Quit: Leaving) | |
07:31 | mikkel has joined IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net) | |
07:32 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
07:39 | Enslaver has left IRC (Enslaver!~Enslaver@fedora/Enslaver, Read error: Connection reset by peer) | |
07:41 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 248 seconds) | |
07:42 | Enslaver has joined IRC (Enslaver!~Enslaver@fedora/Enslaver) | |
08:04 | khildin has joined IRC (khildin!~khildin@ip-213-49-84-217.dsl.scarlet.be) | |
08:35 | sd34 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:58 | Fenuks 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:02 | bennabiy 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:04 | bennabiy 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:21 | Grembler 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:25 | bobby_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:42 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
10:18 | workingcats has joined IRC (workingcats!~workingca@212.122.48.77) | |
10:42 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
10:43 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard) | |
11:00 | q2dg 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:08 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
11:09 | <q2dg> Ok, thanks a lot
| |
11:29 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
11:35 | Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 268 seconds) | |
11:57 | david007co2 has joined IRC (david007co2!~androirc@186.28.209.238) | |
12:04 | Fenuks has joined IRC (Fenuks!~Fenuks@109.202.25.212) | |
12:16 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
12:33 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Ping timeout: 245 seconds) | |
12:58 | david007co2 has left IRC (david007co2!~androirc@186.28.209.238, Ping timeout: 268 seconds) | |
12:59 | Fenuks has left IRC (Fenuks!~Fenuks@109.202.25.212, Ping timeout: 245 seconds) | |
13:27 | david007co2 has joined IRC (david007co2!~androirc@190.24.160.36) | |
13:32 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out) | |
13:36 | q2dg has left IRC (q2dg!5f15c1fd@gateway/web/freenode/ip.95.21.193.253, Quit: Page closed) | |
13:43 | dsugar100 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:11 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
14:16 | sd34 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:25 | brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-mcqgrdklyjnzdojd, Quit: Leaving.) | |
14:26 | brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-ctbuaunxvtoyqsve) | |
14:48 | dsugar100 has left IRC (dsugar100!~dsugar@columbia.tresys.com, Remote host closed the connection) | |
14:54 | brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-ctbuaunxvtoyqsve, Quit: Leaving.) | |
15:09 | dsugar100 has joined IRC (dsugar100!~dsugar@columbia.tresys.com) | |
15:25 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
15:38 | gbit 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:41 | mikkel has left IRC (mikkel!~mikkel@80-199-146-42-static.dk.customer.tdc.net, Quit: Leaving) | |
16:02 | PhoenixSTF has joined IRC (PhoenixSTF!~rudi@bl9-43-215.dsl.telepac.pt) | |
16:04 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
16:12 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.) | |
16:26 | Jason_ 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:28 | willianmazzardo 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:34 | Phantomas1 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:35 | Phantomas 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:40 | willianmazzardo 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:41 | PhoenixSTF 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:44 | Jason_ 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:08 | alexqwesa 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:17 | david007co2 has left IRC (david007co2!~androirc@190.24.160.36, Ping timeout: 246 seconds) | |
17:27 | <vagrantc> gbit: set LANGin lts.conf
| |
17:27 | willianmazzardo 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:35 | david007co2 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:36 | bennabiy 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:48 | bennabiy 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:56 | brunolambert 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:11 | vmlintu 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:13 | yanu 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:14 | yanu has joined IRC (yanu!~yanu@178-117-230-250.access.telenet.be) | |
18:14 | yanu 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:19 | david007co2 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:30 | freedomrun 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:34 | david007co2 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:42 | workingcats 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:51 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
18:51 | * vagrantc waves to alkisg | |
18:52 | <alkisg> Hi vagrantc, hi all
| |
18:52 | Grembler 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:02 | adrianorg 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:04 | adrianorg 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:15 | khildin 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:21 | awilliam1 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:22 | awilliams has left IRC (awilliams!~awilliams@unaffiliated/mistik1, Ping timeout: 245 seconds) | |
19:22 | awilliam1 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:31 | willianmazzardo 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:35 | freedomrun 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:36 | alexqwesa 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:42 | Andymeows 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:50 | kev_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:17 | Phantomas1 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:04 | kev_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:12 | vmlintu 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:23 | Lumiere 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:42 | Lumiere has joined IRC (Lumiere!~jstraw@unaffiliated/jstraw) | |
21:42 | david007co2 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:56 | brunolambert 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:58 | brunolambert 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:13 | yanu 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:14 | yanu 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:32 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
22:38 | GrembleBean has joined IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net) | |
22:43 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
23:07 | Andymeows has left IRC (Andymeows!~Andymeows@173-11-52-41-Minnesota.hfc.comcastbusiness.net, Ping timeout: 285 seconds) | |
23:58 | awilliams has left IRC (awilliams!~awilliams@unaffiliated/mistik1, Ping timeout: 240 seconds) | |