IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 20 May 2016 (all times are UTC)
| 00:43 | <sbalneav> Evening all
| |
| 01:05 | <Leolo_2> hello
| |
| 01:19 | <sbalneav> Hey Leolo_2
| |
| 03:24 | ls
| |
| 03:37 | rac__ has left IRC (rac__!71148af6@gateway/web/freenode/ip.113.20.138.246, Ping timeout: 250 seconds) | |
| 03:38 | rac_ has left IRC (rac_!71148af6@gateway/web/freenode/ip.113.20.138.246, Ping timeout: 250 seconds) | |
| 04:54 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 05:04 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 276 seconds) | |
| 06:00 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:8d78:d090:dc40:ca8e) | |
| 06:18 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 06:50 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:8d78:d090:dc40:ca8e, Ping timeout: 260 seconds) | |
| 07:01 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 07:04 | kjackal has joined IRC (kjackal!~quassel@onopfy.static.otenet.gr) | |
| 07:50 | gdi2k has left IRC (gdi2k!~gdi2k@49.151.17.102, Ping timeout: 276 seconds) | |
| 08:03 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 08:03 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 09:12 | Buho has joined IRC (Buho!533cc51c@gateway/web/freenode/ip.83.60.197.28) | |
| 09:18 | badgerbailey has joined IRC (badgerbailey!31e48b8a@gateway/web/freenode/ip.49.228.139.138) | |
| 09:19 | <badgerbailey> Hi, I wonder if someone could help, I installed LTSP-server-standalone, installed the ltsp image I think I setup my 2 onboard lan correctly but I cannot connect to server via virtualbox on my laptop
| |
| 09:20 | DHCP timeouts happening
| |
| 09:22 | I have a staic IP on the first network port eno1 which connects to my router for outside internet access, on my second eno2 port I set a static IP but the virtualbox doesn't seem to get an IP or begin to download the image
| |
| 09:23 | eno1 ststic IP is 192.168.1.50 for outside access, eno2 static IP is 192.168.0 1, anyone have any idea how to test to see where the propblem lies?
| |
| 09:23 | <alkisg> badgerbailey: dhcp broadcasts don't go to bridged adapters, if that's what you're asking
| |
| 09:24 | That's a #vbox issue though
| |
| 09:24 | If you were using an external dhcp server, it would work fine
| |
| 09:24 | <badgerbailey> the guide I followed suggested to set it up this way, and test with a bridged adapter from my windows laptop
| |
| 09:24 | <alkisg> Or an internal network vbox client
| |
| 09:25 | Are you setting up ltsp for the first time?
| |
| 09:25 | <badgerbailey> yes
| |
| 09:25 | trying
| |
| 09:25 | <alkisg> !ltsp-pnp
| |
| 09:25 | <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
| |
| 09:25 | <alkisg> This is the best guide, if it fit your needs
| |
| 09:25 | <badgerbailey> thanks I'll take a look now
| |
| 09:25 | <alkisg> What are your client specs?
| |
| 09:25 | cpu/ram and how many?
| |
| 09:26 | <badgerbailey> 25 clients running chrome browser and a simple office suite, thats all
| |
| 09:26 | my server has xeon e3 1231v2, 32gb ram
| |
| 09:27 | <alkisg> badgerbailey: how much ram do your clients have? and what cpu?
| |
| 09:28 | <badgerbailey> I am trying to test with pretty basic thin clients see here: http://www.inctel.com.cn/product/detail/39
| |
| 09:29 | <alkisg> It's best if the clients have enough cpu/ram to run the os locally
| |
| 09:29 | They'll still be diskless and netbooted, but they won't use the server cpu/ram
| |
| 09:29 | We call that "ltsp fat clients", it works much better than ltsp thin clients
| |
| 09:29 | ltsp-pnp supports both models out of the box
| |
| 09:30 | But if you have already bought the clients and they're allwinner, then no, fat clients won't do for you
| |
| 09:32 | Hmm also, those are ARM, right? Did you create an armhf chroot?
| |
| 09:32 | <badgerbailey> okay, before starting from scratch do you know of any guide to help me fix what I have now and check the situation to see if my NIC's are configured correctly?
| |
| 09:33 | <alkisg> badgerbailey: do you know that your clients have an ARM cpu and that you need an ARM chroot to boot them?
| |
| 09:33 | <badgerbailey> no i didn't, is it possible to add in this feature or will I need to start from scratch?
| |
| 09:34 | <alkisg> It makes things much more difficult for you
| |
| 09:34 | And guides more hard to find
| |
| 09:34 | How many of those clients do you already have?
| |
| 09:35 | <badgerbailey> only 1 for test so its not an issue to change, I'm just trying to keep the costs down, its for a charity so I am bearing the whole cost of this project
| |
| 09:35 | <alkisg> These things are like raspberry pis
| |
| 09:35 | They have special processors and it's more hard to manage them
| |
| 09:35 | It's much much easier if you have PCs as clients, x86 based
| |
| 09:36 | For example, those are x86: http://www.inctel.com.cn/product/35
| |
| 09:36 | So what I'm suggesting to you is this:
| |
| 09:36 | 1) Start from scratch and follow the ltsp-pnp guid
| |
| 09:36 | e
| |
| 09:37 | 2) Test with some PCs that you have around to verify that fat clients work best
| |
| 09:37 | 3) Buy x86 clients as your ltsp clients
| |
| 09:37 | (and throw away that ARM client that you have, it's not worth the trouble)
| |
| 09:38 | <badgerbailey> these are pretty cheap also, I guess x86 x64
| |
| 09:38 | http://www.lazada.co.th/mini-pc-silver-4246460.html
| |
| 09:39 | <alkisg> To evaluate clients, mark their CPUs and look it up in this site:
| |
| 09:39 | https://www.cpubenchmark.net/cpu.php?cpu=Intel+Atom+Z3735F+%40+1.33GHz
| |
| 09:39 | So the clients that you said now, have 909 score
| |
| 09:39 | They will work. But my 7 year old laptop has 1500 score.
| |
| 09:40 | So they're similar to buying an 8-10 year old computer...
| |
| 09:40 | For *light* surfing, 1000 score is acceptable. Normally we only buy new clients with score > 2000.
| |
| 09:40 | E.g. core i3 has 5000 score
| |
| 09:40 | <badgerbailey> okay got it
| |
| 09:41 | <alkisg> Btw with ltsp fat clients, your server can be a simple PC, it doesn't need to be expensive
| |
| 09:43 | <badgerbailey> okay, thanks for your info
| |
| 09:45 | <alkisg> You're welcome
| |
| 09:54 | <Hyperbyte> Hello mr alkisg!
| |
| 09:54 | <alkisg> Haha, hello Hyperbyte, it looks like I'm the only one he wants to speak to :D
| |
| 10:01 | eu^ip-92-42-113- has joined IRC (eu^ip-92-42-113-!5c2a716b@gateway/web/freenode/ip.92.42.113.107) | |
| 10:01 | <eu^ip-92-42-113-> hi all
| |
| 10:02 | problem: epoptes verify error:num=18:self signed certificate
| |
| 10:03 | ..and client is not visible by epo-server...but Successfully fetched certificate from 192.168.1.140:789
| |
| 10:06 | <alkisg> Hello eu^ip-92-42-113-
| |
| 10:07 | Do you have something weird with regards to your root certificates?
| |
| 10:07 | Is your computer date/time ok?
| |
| 10:09 | lbssousa has joined IRC (lbssousa!~lbssousa@177.143.28.213) | |
| 10:10 | badgerbailey has left IRC (badgerbailey!31e48b8a@gateway/web/freenode/ip.49.228.139.138, Quit: Page closed) | |
| 10:12 | <eu^ip-92-42-113-> time from internet
| |
| 10:13 | epoptes-client run great on lubuntu 15.04 but this problem is with ubuntu 15.10
| |
| 10:14 | <alkisg> eu^ip-92-42-113-: what is your server called? Did you put "server" in /etc/hosts?
| |
| 10:15 | <eu^ip-92-42-113-> yes same on ubuntu & lubuntu...
| |
| 10:15 | <alkisg> OK, can you try this from your client?
| |
| 10:15 | EPOPTES_CLIENT_VERIFY_CERTIFICATE=False epoptes-client
| |
| 10:15 | This is a single command, copy/paste it
| |
| 10:15 | If you run that, can you then see the client in the epoptes UI?
| |
| 10:17 | <eu^ip-92-42-113-> ok server can see my ub 15.10 great thnx ;)
| |
| 10:17 | <alkisg> Wait
| |
| 10:17 | This was temporary
| |
| 10:17 | <eu^ip-92-42-113-> ok
| |
| 10:17 | <alkisg> You need to upgrade your epoptes client to 0.5.10
| |
| 10:17 | Use the epoptes PPA to do that
| |
| 10:18 | Do you know how?
| |
| 10:19 | <eu^ip-92-42-113-> put ppa to apt-get, update, iremove old ver, instal new?
| |
| 10:20 | <alkisg> sudo add-apt-repository ppa:epoptes; sudo apt-get update; sudo apt-get dist-upgrade
| |
| 10:20 | That's all
| |
| 10:20 | The problem was in socat, we've fixed it in newer epoptes versions
| |
| 10:21 | <eu^ip-92-42-113-> upgrading now........
| |
| 10:29 | robb_nl has joined IRC (robb_nl!~robb_nl@ip-83-134-2-72.dsl.scarlet.be) | |
| 10:39 | kjackal_ has joined IRC (kjackal_!~quassel@onopfy.static.otenet.gr) | |
| 10:39 | kjackal has left IRC (kjackal!~quassel@onopfy.static.otenet.gr, Read error: Connection reset by peer) | |
| 10:58 | adrianorg has left IRC (adrianorg!~adrianorg@179.187.25.178.dynamic.adsl.gvt.net.br, Ping timeout: 260 seconds) | |
| 11:00 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.169.131) | |
| 11:03 | eu^ip-92-42-113- has left IRC (eu^ip-92-42-113-!5c2a716b@gateway/web/freenode/ip.92.42.113.107, Ping timeout: 250 seconds) | |
| 11:20 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.169.131, Ping timeout: 244 seconds) | |
| 11:22 | adrianorg has joined IRC (adrianorg!~adrianorg@177.134.56.43) | |
| 11:34 | adrianorg has left IRC (adrianorg!~adrianorg@177.134.56.43, Ping timeout: 276 seconds) | |
| 11:36 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.99.189) | |
| 11:36 | Statler_ has joined IRC (Statler_!~Georg@p54BFB071.dip0.t-ipconnect.de) | |
| 11:37 | <Statler_> ltsp-localapps seems not to retrun exit code?
| |
| 11:37 | something like "ltsp-localapps firefox || firefox" doesn't work
| |
| 11:38 | I have x2go-clients on the same server, where ltsp-localapps cannot have success
| |
| 11:38 | in these case I want to define a "fallback" to the serverside app
| |
| 11:42 | robb_nl has left IRC (robb_nl!~robb_nl@ip-83-134-2-72.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 11:45 | xenthree3 has joined IRC (xenthree3!~xenthree3@h42-57.pool95-168.dyn.tolna.net) | |
| 11:45 | xenthree3 has left IRC (xenthree3!~xenthree3@h42-57.pool95-168.dyn.tolna.net) | |
| 11:45 | kjackal_ has left IRC (kjackal_!~quassel@onopfy.static.otenet.gr, Ping timeout: 252 seconds) | |
| 11:48 | Faith has joined IRC (Faith!~paty_@unaffiliated/faith) | |
| 11:51 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.99.189, Ping timeout: 260 seconds) | |
| 11:52 | adrianorg has joined IRC (adrianorg!~adrianorg@186.213.154.21) | |
| 12:07 | Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 12:12 | GodFather_ has joined IRC (GodFather_!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 12:14 | GodFather_ has left IRC (GodFather_!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Client Quit) | |
| 12:14 | GodFather_ has joined IRC (GodFather_!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 12:14 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 260 seconds) | |
| 12:14 | GodFather_ is now known as GodFather | |
| 12:15 | adrianorg has left IRC (adrianorg!~adrianorg@186.213.154.21, Ping timeout: 240 seconds) | |
| 12:16 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:e420:9361:bc6d:ca35) | |
| 12:17 | adrianorg has joined IRC (adrianorg!~adrianorg@177.134.62.136) | |
| 12:17 | GodFather is now known as GodFodder | |
| 12:56 | Leolo_2 has left IRC (Leolo_2!~fil@24-54-31-128.mg.cgocable.ca, Ping timeout: 260 seconds) | |
| 13:28 | gdi2k has joined IRC (gdi2k!~gdi2k@49.151.17.102) | |
| 13:32 | <sbalneav> Statler_: You're right, it doesn't, but there's no easy way to make it to.
| |
| 13:33 | ltsp-localapps just sets an xprop, then asynchronously, the command is run.
| |
| 13:34 | There isn't a good way to pass the exit code of the program back to ltsp-localapps.
| |
| 13:38 | <||cw> does it need to be async?
| |
| 13:40 | <sbalneav> The thin client doesn't have an ssh server running on it. So the only method of communication to go back from the server to the client is via the X server itself.
| |
| 13:40 | X itself doesn't have any provision for an "exec" function, so what we did was define an X prop that sits on the root window.
| |
| 13:40 | We have a "server" that runs on the thin client, that listens for changes to this property
| |
| 13:41 | On the LTSP server, you essentially just change this property with the name of the program you want to execute.
| |
| 13:42 | On the thin client, this server process that's listening to the property changes then executes the program requested.
| |
| 13:43 | So the ltsp-localapps script isn't actually doing any executing, it's just setting an xprop.
| |
| 13:44 | So long as it succeeds at setting the xprop, ltsp-localapps "succeeds"
| |
| 13:44 | if the server process running on the thin client can't execute the program, the ltsp-localapps script doesn't know about it.
| |
| 13:45 | <||cw> ah
| |
| 13:45 | jamorais has joined IRC (jamorais!bb4c818e@gateway/web/freenode/ip.187.76.129.142) | |
| 13:46 | <jamorais> ok! Good morning!
| |
| 13:46 | <sbalneav> Morning jamorais
| |
| 13:46 | <||cw> so to make it async, you'd need the script to wait for the client to send something back over ssh or whatever, maybe look for a file to be touched, with a timeout, which could get error prone
| |
| 13:47 | <sbalneav> It would be much harder to do, yes.
| |
| 13:47 | <jamorais> My english is very poor, but let's go to chat
| |
| 13:47 | <||cw> woulnd't be hard to implement, but would be hard to make reliable, and would likely slow down the non-thin clients a lot
| |
| 13:47 | <jamorais> This IRC is about Epoptes?
| |
| 13:48 | <sbalneav> jamorais: It's about LTSP, and Epoptes. I don't know anything about Epoptes myself, however.
| |
| 13:49 | But ask your question, and hang around several hours for the answer, and hopefully when someone who does know sees it, they'll respond.
| |
| 13:50 | <jamorais> There any version of Epoptes that have options put time on clients?
| |
| 13:50 | <sbalneav> "Put time"?
| |
| 13:50 | You mean set the clock?
| |
| 13:51 | <jamorais> Yes! thirty minutes for exemple
| |
| 13:51 | Here is a computers labs
| |
| 13:51 | <sbalneav> Oh, you mean set a login limit.
| |
| 13:52 | I don't know. alkisg would be the fellow to ask.
| |
| 13:52 | <jamorais> Yes!
| |
| 13:52 | Here labs computers at school
| |
| 13:52 | <sbalneav> alkisg would know. Hang around and wait for him to become active.
| |
| 13:53 | <jamorais> And the students, do not stop use a computers
| |
| 13:54 | Here I am testing Epoptes wiht LTSP.
| |
| 13:57 | jamorais has left IRC (jamorais!bb4c818e@gateway/web/freenode/ip.187.76.129.142) | |
| 14:16 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:18 | <alkisg> jamorais, it wasn't an epoptes issue, the easiest way to do what you wanted would be to set a screensaver that exited the session, i.e. an ltsp issue :)
| |
| 14:22 | <||cw> so much for "hang around several hours"
| |
| 14:22 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 14:22 | <alkisg> Statler_: it's possible to patch ltsp-localapps / ltsp-localappsd to support an additional LTSP_COMMAND_RESULT xprop that travels the other way
| |
| 14:23 | If you send a proper implementation of that, I don't see why it wouldn't get accepted
| |
| 14:29 | <sbalneav> alkisg: Problem with that would be, you'd somehow have to queue results.
| |
| 14:29 | <||cw> how quickly does the client side get the message?
| |
| 14:29 | <sbalneav> right now, if you do "ltsp-localapps xxx; ltsp-localapps yyy; ltsp-localapps zzz", all 3 will launch fine.
| |
| 14:30 | <alkisg> sbalneav: one easy way would be to use mktemp to get a random LTSP_COMMAND_RESULT_XXXXX name, and pass it to ltsp-localappsd
| |
| 14:30 | <||cw> sbalneav: no it would still work fine since ltsp-localapps would wait for the reply before exiting
| |
| 14:31 | <alkisg> ||cw: many processes can run in parallel though
| |
| 14:31 | Even from different user shells
| |
| 14:31 | <sbalneav> ||cw: That means you can only run one localapp at a time, though.
| |
| 14:31 | alkisg: Not sure how we'd do the server side, registering and listening for xprops.
| |
| 14:32 | <alkisg> Similar to how ltsp-localappsd does it, i.e. wait for LTSP_COMMAND_RESULT_XXXX to change, but only for 1-2 seconds, and return failure if the timeout passes
| |
| 14:32 | <||cw> would a file be simpler?
| |
| 14:33 | <alkisg> I see this as a minor feature request, so no worries I'm not suggesting to implement it :D
| |
| 14:33 | But I wouldn't object to a proper patch that does implement it if Statler_ wanted to do it
| |
| 14:33 | <sbalneav> Agreed.
| |
| 14:33 | MRH2 has joined IRC (MRH2!~Thunderbi@233.47.187.81.in-addr.arpa) | |
| 14:33 | <||cw> server touches a temp file, sends filename with the xprop, client deletes file, server sees it and returns success, but with a X second timeout where server deletes the file and returns fail
| |
| 14:34 | <Statler_> another way was to clear determine if the client is really a ltsp-client
| |
| 14:34 | <alkisg> ||cw: yup, ssh can be used for that, listening on a socket is easy too
| |
| 14:35 | <MRH2> general q does the greek schools ppa get updated in to the main ltsp package?
| |
| 14:35 | <alkisg> localapps could also be implemented by listening to the ltsp's ssh stdin, i.e. right after the "echo LTSPROCKS" part
| |
| 14:35 | MRH2: I'm updating the greek schools ppa whenever there are significant changes in ltsp, yes
| |
| 14:37 | <Statler_> is there something in the environment variables that I can evaluate to determine if I have a ltsp-client or something else?
| |
| 14:39 | <MRH2> sorry i meant the other way around as the greek ppa seems to lead at least when i last tested the 2. or does development from the greek schools go directly in to ltsp.
| |
| 14:40 | <alkisg> MRH2: I'm an ltsp developer and I'm also maintaining the greek schools ppa. When some significant work is done in ltsp, I'm releasing new versions to the PPA. After some time, distros also get it. For Ubuntu 16.04, those two are temporarily in sync.
| |
| 14:41 | Statler_: echo $LTSP_CLIENT
| |
| 14:41 | <MRH2> ok cool so u release to both
| |
| 14:41 | i was wondering how they stay in sync
| |
| 14:43 | <alkisg> I'm not in charge of releasing to any distros, those happen by their maintainers
| |
| 14:43 | Although I'll probably start to maintain ltsp in ubuntu since 16.04...
| |
| 14:46 | <Statler_> tank you alkisg
| |
| 14:46 | thank
| |
| 14:47 | I see my problem: I'm via x2go logged in ;)
| |
| 14:47 | I must take a thin client to test the environment
| |
| 14:48 | <MRH2> i guess i see development more on ur side and concerned about things becoming diverged
| |
| 14:48 | :)
| |
| 14:54 | even an official ltsp-non-chroot
| |
| 14:55 | <alkisg> MRH2: all my ltsp development goes upstream, or locally in "sch-scripts", none of it goes only to the ppa
| |
| 14:55 | <MRH2> ah
| |
| 14:55 | cool
| |
| 14:56 | thanks for clearing that up alkisg :)
| |
| 15:08 | lmds_ has left IRC (lmds_!~lmds@tui.pi-et-ro.net, Ping timeout: 240 seconds) | |
| 15:18 | metaf5 has left IRC (metaf5!~metaf5@31.220.42.38, Ping timeout: 260 seconds) | |
| 15:26 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:e420:9361:bc6d:ca35, Quit: No Ping reply in 180 seconds.) | |
| 15:27 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2) | |
| 15:31 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2, Client Quit) | |
| 15:32 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2) | |
| 15:34 | GodFodder has left IRC (GodFodder!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Remote host closed the connection) | |
| 15:45 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 16:22 | Leolo_2 has joined IRC (Leolo_2!~fil@24-54-31-128.mg.cgocable.ca) | |
| 16:28 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2, Ping timeout: 260 seconds) | |
| 16:34 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:e420:9361:bc6d:ca35) | |
| 16:35 | Phantomas has left IRC (Phantomas!~ftsamis@ubuntu/member/phantomas, Remote host closed the connection) | |
| 16:40 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 276 seconds) | |
| 16:45 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:e420:9361:bc6d:ca35, Ping timeout: 260 seconds) | |
| 16:48 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2) | |
| 16:49 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 17:28 | lmds_ has joined IRC (lmds_!~lmds@tui.pi-et-ro.net) | |
| 17:35 | <vsuojanen> Hi, has anyone played with Edubuntu Live USB?
| |
| 17:35 | https://edubuntu.org/documentation/ltsp-live
| |
| 17:35 | <alkisg> vsuojanen: edubuntu isn't really active any longer
| |
| 17:35 | <vsuojanen> is it still ..ok ? :)
| |
| 17:36 | <alkisg> No, it didn't even ship a 16.04 version
| |
| 17:36 | That said, it's really easy to ship a live ltsp in a usb stick
| |
| 17:36 | Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving) | |
| 17:36 | <vsuojanen> it was 6th or 7th in google results for 'ltsp'
| |
| 17:40 | alkisg: I tried the live ltsp method and I liked it. There were cons also
| |
| 17:41 | <alkisg> vsuojanen: I'm usually having a full ltsp installation in a usb stick, but instead of using /opt/ltsp/images/i386.img, I'm directly exporting /dev/sdb1, so that more caching is done, and it's a lot faster that way, and saves a lot of space
| |
| 17:44 | <vsuojanen> it's easy and fast to setup but there is ldm that needs connection to the server and then there is grub with default recovery feature. it has some annoyant issue with the server when it boots overlayfs
| |
| 17:44 | <alkisg> LDM on the stick? No, it's using lightdm
| |
| 17:44 | <vsuojanen> the annoyant issue is default grub recovery
| |
| 17:45 | <alkisg> I've never seen the issues you say, I don't know what method you used
| |
| 17:45 | I've never used edubuntu's live ltsp usb stick method
| |
| 17:46 | <vsuojanen> I followed your mehthod... it was couple months back that you mentioned that
| |
| 17:47 | http://irclogs.ltsp.org/?d=2015-09-17
| |
| 17:47 | <alkisg> Was it the "regular installation" method, or the "nbd image in a stick" method? looking...
| |
| 17:48 | Ah, that's the cow method, to prevent the stick from being overused
| |
| 17:48 | <vsuojanen> anyways i did not use ldm but switched to lightdm. yes. nbd image in stick method :)
| |
| 17:48 | <alkisg> No no that's a third method
| |
| 17:48 | It's a regular installation with cow booting
| |
| 17:49 | It's hard to set it up properly, but it's very flexible
| |
| 17:50 | To omit LDM, you create /etc/lts.conf with a couple of directives
| |
| 17:51 | That way you can use lightdm in cow mode
| |
| 17:51 | <vsuojanen> i would set up it for first ltsp installation or demo
| |
| 17:51 | <alkisg> KEEP_DEFAULT_DISPLAY_MANAGER=True or something
| |
| 17:52 | Also I don't see why grub recovery would be activated, I never got that bug either
| |
| 17:56 | <vsuojanen> to me it didn't activate grub recovery because grub or ubuntu/debian developers have made default GRUB_RECORDFAIL_TIMEOUT=30 when recordfail=1. and grub or ubuntu sets recordfail=1 in /etc/grub.d/00-header
| |
| 17:57 | so the annoyance was 30s timeout for booting after the very first boot
| |
| 18:00 | i did not go further with such small issue but I think that was related to overlayfs and ubuntu grub2 configs
| |
| 18:01 | <alkisg> It sounds reasonable... I didn't use the ubuntu grub2 configuration that's probably why I didn't see it
| |
| 18:01 | It would be easy to remove recordfail, or to reset it from the ltsp initramfs script
| |
| 18:01 | <vsuojanen> yeah. I really missed syslinux when i searched the reason for that issue
| |
| 18:04 | MRH2 has left IRC (MRH2!~Thunderbi@233.47.187.81.in-addr.arpa, Quit: MRH2) | |
| 18:39 | Statler_ has left IRC (Statler_!~Georg@p54BFB071.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 19:18 | <Leolo_2> can things like LDM_FORCE_SESSION=xfce get set in lts.conf?
| |
| 19:32 | <sbalneav> Leolo_2: Is that currently something we honour?
| |
| 19:38 | <alkisg> Yup to both questions :)
| |
| 19:39 | Actually putting it in lts.conf is exactly what it was coded for
| |
| 19:39 | <sbalneav> I can't remember all the lts.conf variables anymore :D
| |
| 19:39 | <alkisg> I don't think anyone ever has, we didn't even manage to document all of them!
| |
| 19:40 | <sbalneav> https://code.launchpad.net/~ltsp-upstream/+git/libpam-external
| |
| 19:41 | <alkisg> sbalneav: external? what's that for?
| |
| 19:41 | Hehe, git!
| |
| 19:41 | <sbalneav> So, one of the issues is always the C coding.
| |
| 19:42 | we're hoping to reduce it down to libpam-sshauth, but then I got the brilliant idea.
| |
| 19:42 | <alkisg> "Can't do it. I hate the switch statement." Hahaha
| |
| 19:42 | <sbalneav> What if I wrote a pam module.... that wasn't a pam module?
| |
| 19:42 | <alkisg> And code the rest of it in shell?
| |
| 19:43 | <sbalneav> Instead, it just acts as a shim... and passes pam messages, via stdin and stdout, to some external program
| |
| 19:43 | right.
| |
| 19:43 | !paste
| |
| 19:43 | <ltsp`> paste: the LTSP pastebin is at http://ltsp.pastebin.com. Please paste all text longer than a line or two to the pastebin, as it helps to reduce traffic in the channel. Don't forget to paste the URL of the text here.
| |
| 19:43 | <alkisg> I was thinking to implement ldm in shell, and keep the greeter in python...!
| |
| 19:43 | <sbalneav> http://pastebin.com/KKWEmvhU
| |
| 19:44 | It's not complete, but with libpam_external, and that bit of python, it does most of what libpam_sshauth does.
| |
| 19:44 | And all the ssh-y bits are in python.
| |
| 19:44 | <alkisg> That's a very good idea :)
| |
| 19:44 | <sbalneav> So:
| |
| 19:45 | I've got lightdm-webkit(2)-greeter whipped into shape
| |
| 19:45 | So we can write greeters in html/js
| |
| 19:45 | <quinox> :o
| |
| 19:46 | <sbalneav> I've now got (or in the process of getting) libpam_external and libnss_external close to being in testable condition, so we can script PAM and NSS stuff in scripting language.
| |
| 19:46 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 19:47 | <sbalneav> So, apart from nss/pam_external all the stuff that LTSP6 could use would be... scripts.
| |
| 19:47 | We shall see. Some more work left to do. Some, haha. Lots.
| |
| 19:47 | But, I'm excited.
| |
| 19:49 | I'm writing the man page for libpam_external now.
| |
| 19:49 | <alkisg> Cool!! Hopefully me and vagrantc will make it to debconf16 and make some progress with the pam integration there
| |
| 19:49 | * alkisg needs to go pick up the kids, later! :) | |
| 19:49 | <sbalneav> WHere's that?
| |
| 19:50 | ah, yeah, sa
| |
| 19:59 | lbssousa has left IRC (lbssousa!~lbssousa@177.143.28.213, Quit: Leaving) | |
| 20:02 | epoptes_user9 has joined IRC (epoptes_user9!b187c003@gateway/web/freenode/ip.177.135.192.3) | |
| 20:03 | kjackal has left IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2, Ping timeout: 260 seconds) | |
| 20:10 | <Leolo_2> alksig : having PAM run shell code is about as secure as something very unsecure
| |
| 20:11 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3117:9e00:790f:ff4d:499c:57c2) | |
| 20:13 | <sbalneav> Leolo_2: There are already several pam modules that execute shell code.
| |
| 20:13 | One ships as part of pam.
| |
| 20:14 | pam_exec, pam_script, etc.
| |
| 20:14 | In fact, pam_script sets PAM_AUTHTOK and PAM_OLDAUTHTOK as environment variables :D
| |
| 20:14 | Which, I'd like to point out, I'm not doing. :D
| |
| 20:15 | Leolo_2: https://code.launchpad.net/~ltsp-upstream/+git/libpam-external
| |
| 20:15 | If you have any comments or would like to make suggestions to the code, feel free. I'm developing it now.
| |
| 20:16 | <Leolo_2> just the general idea that PAM is running a shell script rubs me all wrong
| |
| 20:16 | yeah, pam_exec can do that... but pam_exec can't authorize anyone
| |
| 20:17 | <sbalneav> pam_script can
| |
| 20:17 | * Leolo_2 shakes his head in disbelief | |
| 20:17 | <Leolo_2> what is the world coming to !
| |
| 20:17 | <sbalneav> So, do you have an *actual* objection, or do you just not like it?
| |
| 20:19 | Like I say, have a look at the code, and if you feel something's not right, I'm all ears.
| |
| 20:19 | <Leolo_2> I thought it was clear from the begining that it was "just not like it"
| |
| 20:20 | I've been reading LTSP code for the last week. It's very well writen
| |
| 20:20 | I just feel shell scripts are to fragile for something as important as PAM authentification
| |
| 20:20 | I am perfectly prepared to be wrong on this point
| |
| 20:21 | <sbalneav> No, you said it was "about as secure as something very unsecure". I'm asking, specifically, how calling an externel helper program to do the authentication is any less secure than, say writing a pam module in pure C and verifying there's no null pointer exceptions, buffer overflows, etc?
| |
| 20:22 | <Leolo_2> C programs get static checks, shell scripts don't
| |
| 20:22 | so typos are caught early
| |
| 20:23 | C programers know about security issues, and while coding a PAM module (one hopes) put them utmost in their mind
| |
| 20:23 | <sbalneav> I did, when I wrote libpam_sshauth
| |
| 20:24 | I just recently had to file a security bug for unintended root escalation in the module.
| |
| 20:24 | <Leolo_2> yeah, then you get libpam_sshauth which is pretty complex and depends on openssh not having errors in it (safish bet)
| |
| 20:24 | <sbalneav> So? Libpam_ldap is pretty complex and depends on ldap not having errors in it :D
| |
| 20:25 | Errors happen, regardless. And being able to write an authentication module in a modern scripting language without buffer overflow probelms, proper exception handling, etc. Might, in the long run, be *more safe* than custom-coding a pam module in C from scratch every time.
| |
| 20:26 | I'm simply playing devils advocate here.
| |
| 20:26 | <Leolo_2> and I'm listening
| |
| 20:26 | your points are not invalid
| |
| 20:27 | <sbalneav> To the extent that libpam_external would be "error free" and "secure", it then places any potential bugs in an authentication mechanism in a much-easier-to-understand-and-debug program than wading through a PAM module's C source.
| |
| 20:45 | <Leolo_2> if I have an issue with ssh sockets and fuse.unionfs, who should I file a bug with?
| |
| 20:45 | or do I just not bother - pretty sure everyone is going to say "not our problem"
| |
| 20:46 | <sbalneav> https://github.com/rpodgorny/unionfs-fuse?
| |
| 20:47 | That the source for it?
| |
| 20:47 | What's the issue?
| |
| 20:50 | <Leolo_2> ssh -S socket does a bind/listen on socket.RANDOM it then does link( "socket.RANDOM", "socket" ); unlink( "socket.RANDOM" )
| |
| 20:50 | this fails to create a usable socket
| |
| 20:51 | <sbalneav> ok, is that the source? If so, I can dig into it this long weekend, and try to find where the problem is.
| |
| 20:52 | Always easier to get a problem looked at if you can a) identify exactly where in the code the problem is or b) (ideally) include a patch in the bug report :D
| |
| 20:53 | <Leolo_2> well if I change the link/unlink to rename, it works
| |
| 20:54 | <sbalneav> in ssh? Unlikely they'll accept a patch; the openssh guys are very unwilling to accept any input from outside the "golden circle" of ssh devels.
| |
| 20:55 | So it'd be far easier to find out what in the unionfs-fuse semantics causes it to fail, and fix that.
| |
| 20:55 | We've tried before to get things looked at in ssh here in ltspland :D
| |
| 21:05 | <Leolo_2> another work around would be to have LDM_SSH_EXEC=/opt/openssh/ssh
| |
| 21:05 | and have plugins/ssh/ssh.c respect that
| |
| 21:08 | https://github.com/rpodgorny/unionfs-fuse/issues/46
| |
| 21:52 | <alkisg> (11:11:00 μμ) Leolo_2: alksig : having PAM run shell code is about as secure as something very unsecure ==> security isn't in the language, it's in the programmer
| |
| 21:57 | Leolo_2: btw, can't you use some more recent kernel now that overlayfs is mainlined? doesn't centos have backported kernels?
| |
| 22:04 | !learn alkisg-todo as test the null cipher with https://launchpad.net/~yoda-jazz-kc/+archive/ubuntu/hpn-ssh
| |
| 22:04 | <ltsp`> The operation succeeded.
| |
| 22:04 | <alkisg> !alkisg-todo
| |
| 22:04 | <ltsp`> alkisg-todo: (#1) support xnbd-proxy for local caching: https://bitbucket.org/hirofuchi/xnbd/wiki/Home#!scenario-2-simple-proxy-server-distributed-copy-on-write, or (#2) Support UEFI, or (#3) support for per-user login commands in lts.conf, or (#4) put panic=60 in the kernel cmdline, or (#5) document bind-interfaces, or (#6) test aes-ni instruction set for faster ssh, or (#7) test the null cipher with https://launchpad.net (1 more message)
| |
| 22:04 | <alkisg> !more
| |
| 22:04 | <ltsp`> /~yoda-jazz-kc/+archive/ubuntu/hpn-ssh
| |
| 22:05 | <alkisg> !forget alkisg-todo 6
| |
| 22:05 | <ltsp`> The operation succeeded.
| |
| 22:05 | <Leolo_2> alkisg - maybe
| |
| 22:06 | iirc, elrepo has more recent kernels
| |
| 22:06 | <alkisg> Leolo_2: It would make it more aligned with ltsp upstream
| |
| 22:07 | E.g. ltsp-update-image --cleanup also uses overlayfs, it's not only about the initramfs
| |
| 22:07 | How are things looking so far? Ready to ditch ltsp and go for drbl yet? :)
| |
| 22:08 | <Leolo_2> everything is working to my satisfaction
| |
| 22:08 | next week at some point I deploy
| |
| 22:09 | <alkisg> Nice! If you have any patches that should make it upstream, either under the shared dir or under redhat/ etc, do file bug reports/merge requests etc
| |
| 22:09 | <Leolo_2> one thing is that some of the problems are the LTSP+CentOS is too old (nbd v2 for instance)
| |
| 22:10 | some of the problems is that LTSP does things in ways I don't like, so I do them myself the way I like (/etc/dhcp/dhcpd.conf vs /etc/ltsp/dhcpd.client)
| |
| 22:10 | * alkisg thinks dnsmasq should be the default instead of isc-dhcp... | |
| 22:11 | <Leolo_2> and some problems are because of my current set up (select french vs english based on the province a host boots in)
| |
| 22:11 | <alkisg> or at least someone that uses isc-dhcp, should support it like we do with `ltsp-config dnsmasq`
| |
| 22:11 | <Leolo_2> and further problems because I'm an old crmugdeon
| |
| 22:12 | btw ltsprepo.s3.amazonaws.com seems to be gone
| |
| 22:13 | http://ltsprepo.s3.amazonaws.com/rpm/el6 at least doesn't work
| |
| 22:13 | <alkisg> I don't think we have anyone at the centos/fedora/rhel etc front anymore
| |
| 22:13 | The only one still working with RPMs would be cyberorg, for openSUSE
| |
| 22:14 | So I've never even heard of those repositories
| |
| 22:15 | I think opensuse does offer a cross-distro build service that comes with a repository that you might be able to use...
| |
| 22:18 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 246 seconds) | |
| 22:24 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 22:26 | GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Remote host closed the connection) | |
| 22:27 | GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com) | |
| 23:27 | * Leolo_2 makes the mistake of running dracut -v | |
| 23:28 | <Leolo_2> all that cruft... back in my day you could boot off a floppy !
| |
| 23:37 | so nbd v3 doesn't work on CentOS 6
| |
| 23:50 | nbd-client runs fine
| |
| 23:51 | dd if=/dev/nbd9 of=/dev/stdout count=1024 bs=1 | hexdump -C
| |
| 23:51 | hangs
| |