IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 17 December 2013 (all times are UTC)
| 00:08 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 252 seconds) | |
| 00:25 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 01:56 | gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, Ping timeout: 245 seconds) | |
| 02:09 | gdi2k has joined IRC (gdi2k!~gdi2k@64.69.46.199) | |
| 02:13 | gdi2k has left IRC (gdi2k!~gdi2k@64.69.46.199, Ping timeout: 240 seconds) | |
| 02:31 | gdi2k has joined IRC (gdi2k!~gdi2k@120.28.248.83) | |
| 02:40 | <SeRi> Team, I have a centos 6 setup with ltsp-server 5.4.5-22.el6 all is setup and well. I have notice that my clients hungs on shutting down. Exactly when the device is shuttingdown eth0. It will never power off or reboot. Any ideas how to get pass this small annoyance? :)
| |
| 03:18 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 03:54 | <alkisg> vagrantc: hi, another idea! Instead of reimplementing ldm, how would you feel about using a local 'ltsp-connect' wrapper, which would read ldm_username and ldm_password from ldm.c (i.e. stdin), then call ssh, then create the local user (without exposing ldm_username etc in the environment), and finally would re-ssh as the user to the server?
| |
| 03:54 | The difference now is that only 10 shell lines know ldm_username/password from stdin and until the user owned ssh socket is created
| |
| 03:55 | Or, if you prefer, all that could be done inside ldm.c...
| |
| 03:59 | * alkisg thinks the current solution for remoteapps, i.e. having a root listener, is worse, security-wise, than caching the password long enough to do a second ssh connection... | |
| 04:00 | <alkisg> ...and it wastes some more RAM :D
| |
| 04:13 | (unrelated): $ grep -r REMOTECMD .
| |
| 04:13 | ./server/k12linux/configs/lts.conf: LDM_REMOTECMD=/usr/bin/myloginscript
| |
| 04:13 | ./client/getltscfg/lts.conf: LDM_REMOTECMD=/usr/bin/myloginscript
| |
| 04:13 | ...I don't see REMOTECMD anywhere in the code....
| |
| 04:26 | <vagrantc> alkisg: that seems like it would be best done in ldm itself, at this point ... but maybe that is too hard.
| |
| 04:26 | alkisg: ldm.c (or the ssh plugin ... the c code).
| |
| 04:27 | <alkisg> vagrantc: no problem, I've written more .c code than shell code... I just feel .c is not necessary, it just adds overhead for ldm (not the greeter) :)
| |
| 04:29 | We still want the local user to be added by our shell script, right?
| |
| 04:30 | I.e. ssh.c will call that script before spawning the second ssh connection....
| |
| 04:31 | * alkisg really doesn't like all that .c => shell => .c => shell swapping... | |
| 04:32 | <alkisg> With ldm in shell, it would be much more elegant, the greeter in .c, and all the plumbing in shell...
| |
| 04:33 | Mixing languages via stdin/stdout is fine, I just don't like it when .c or .py programs continuously call shell commands do to the actual work, and the .c or .py code is just a wrapper that can also be done in shell...
| |
| 04:33 | *to do
| |
| 04:34 | * vagrantc nods | |
| 04:34 | <vagrantc> how badly are we doing at that, though, really?
| |
| 04:34 | <alkisg> I really think ldm is a bad wrapper for shell scripts that can be done in < 100 lines of shell itself, safely
| |
| 04:35 | For rdesktop, it just reads the password from the greeter and puts it in the command line (!)
| |
| 04:35 | So the rdesktop plugin could be done in a few lines of shell with no security difference
| |
| 04:36 | pam.c doesn't exist, we could do it easily in shell too,
| |
| 04:36 | and I don't think reading LDM_PASSWORD from stdin in shell, makes it less secure than reading it from ssh.c....
| |
| 04:36 | ....and ssh.c can also be done in e.g. 50 lines of code
| |
| 04:37 | I could post an ldm in shell for review, without committing anything in trunk...
| |
| 04:46 | I think my actual question here is, if I do it well enough (so that it e.g. also supports expired passwords and optionally hashing the password to /etc/shadow which _adds_ security for locking the screen of fat clients), and noone sees any obvious way to exploid LDM_PASSWORD... _then_ would it be OK to push it upstream?
| |
| 04:50 | * vagrantc is more worried about non-obvious methods | |
| 04:50 | <vagrantc> i am not confident in my ability to spot some of these complicated security issues.
| |
| 04:52 | <alkisg> LDM_PASSWORD will be only set between 10 lines of shell code of a single script, not in all of the login scripts...
| |
| 04:53 | It won't even be exported to the environment, so cat /proc/pid/environ as root won't see it
| |
| 04:53 | Only RAM dumping will, which is the same for any language
| |
| 04:54 | And of course anyone with enough rights do dump the RAM could more easily install a keylogger...
| |
| 04:54 | *to
| |
| 04:55 | The only difference that I see between shell and .c, is that in .c we can call memset to clean the password in RAM. That's very hard to do right, and we don't even try it currently, and (wrt keylogger) I don't even see a point in doing so
| |
| 05:22 | <vagrantc> alkisg: so, with all the talk of passwords, how would it handle logins with ssh keys?
| |
| 05:25 | <alkisg> vagrantc: how is it done now? the user types an empty password, and the sysadmin has somehow allowed him to provide the key to the local filesystem?
| |
| 05:27 | <vagrantc> alkisg: i don't think it asks for a password unless one is needed
| |
| 05:27 | <alkisg> OK, and where is the key?
| |
| 05:27 | <vagrantc> alkisg: i think it tries the ssh connection before getting the password
| |
| 05:28 | when i've set it up, i use /root/.ssh/id*.pub
| |
| 05:28 | <alkisg> So the user wouldn't have access to it
| |
| 05:28 | <vagrantc> right
| |
| 05:28 | only works because ldm runs as root, currently
| |
| 05:29 | <alkisg> So, ldm in shell or in c, or even with libpam_sshauth, we couldn't have user-owned ssh socket that way
| |
| 05:29 | ...unless we copied the keys to some user-owned folder...
| |
| 05:29 | <vagrantc> i vaguely recally testing it with libpam_sshauth and it worked...
| |
| 05:29 | since pam runs as root, and creates the user-owned socket
| |
| 05:30 | <alkisg> I don't see how libpam_sshauth can do things that ssh.c or plain shell can't...
| |
| 05:30 | To run ssh from the client as the user, the user must exist and have a folder with the keys that he has access to
| |
| 05:30 | * vagrantc looks at the code, it's been a couple months | |
| 05:31 | <alkisg> But anyways, back to ldm in .c vs in shell comparison, ldm in shell would do exactly what ldm in .c does now
| |
| 05:31 | The exact input/output, the exact file system changes etc
| |
| 05:32 | If libpam_sshauth can do better, then maybe we should start with making an libpam_sshauth.c ldm backend...
| |
| 05:35 | <vagrantc> yeah, ssh keys can't work...
| |
| 05:35 | it just runs ssh as the user
| |
| 05:36 | <alkisg> So we need to decide if we prefer ssh keys OR a user-owned ssh socket
| |
| 05:36 | We could just prefer the keys option...
| |
| 05:36 | <vagrantc> for autologin, i liked keys better, as i could set up passwordless users on the server
| |
| 05:37 | and passwordless users can't do a lot of things, which is exactly how i wanted it
| |
| 05:38 | can't change their password, can't authenticate through other means, etc.
| |
| 05:39 | <alkisg> OK... so let's abort the user-owned ssh socket plan... rewritting ldm in shell is still a good way to move forward in my opinion
| |
| 05:40 | <vagrantc> but the user-owned socket is really realyl important!
| |
| 05:40 | i wany it all.
| |
| 05:40 | someday i'll even be able to type.
| |
| 05:40 | <alkisg> The user owned ssh socket is one way to do remoteapps without an extra process binding together 2 sockets
| |
| 05:41 | <vagrantc> it seems like a lot to invest in when we're looking at switching to something else
| |
| 05:41 | <alkisg> It's not any more important than saving 500 Kb RAM on the client...
| |
| 05:41 | I'm not sure we'll even want to drop the greeter...
| |
| 05:41 | *ever
| |
| 05:42 | And I don't think it's more than a weekend's work...
| |
| 05:42 | <vagrantc> i'm just worried about regression potential
| |
| 05:43 | <alkisg> How about dropping ldm.c, keeping the greeter, adding libpam_sshauth, and writing a small script to interface between the greeter and libpam_sshauth?
| |
| 05:45 | We do have some regression potential there, but we've added libpam_sshauth, which supposedly is the way forward....
| |
| 05:45 | <vagrantc> if we can sanely integrate libpam_sshauth into ldm, that sounds ideal to me.
| |
| 05:46 | * alkisg isn't really sure that he prefers libpam_sshauth over e.g. samba, but anyways it's a starting point, having a shell script that allows the greeter to do local pam-based authentication is the key point in my opinion | |
| 05:46 | * vagrantc nods | |
| 05:46 | <vagrantc> ideally, we just support pam... and everything else comes from that.
| |
| 05:47 | <alkisg> OK, I'll start with testing libpam_sshauth first, I haven't do so yet... bbl!
| |
| 05:47 | <vagrantc> i think the ltsp-pam-examples could actually work with something other than libpam_sshautth
| |
| 05:47 | <alkisg> thanks for the chat!
| |
| 05:47 | <vagrantc> always!
| |
| 05:47 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 06:05 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 06:26 | work_alkisg is now known as alkisg | |
| 06:36 | <alkisg> vagrantc: any how-to's for libpam_sshauth? In a wheezy chroot, can I just install it?
| |
| 06:40 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 265 seconds) | |
| 06:47 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 06:49 | <alkisg> https://wiki.ubuntu.com/libpam-sshauth => Unresolved issues: Is Scott smart enough to write this?
| |
| 06:49 | Hahaha!!!
| |
| 06:50 | * alkisg wouldn't wonder about sbalneav1 intelligence, only about if he has enough lobsters to do so... | |
| 07:15 | <alkisg> 50-init-commands: env | sed -n 's/^LTSP_INIT_COMMAND_[0-9][0-9]=//p' | sh
| |
| 07:15 | good enough? ^
| |
| 07:18 | * alkisg will install libpam-sshauth in his trusty box, generate a chroot via ltsp-pnp, and will try to configure libpam_sshauth from LTSP_INIT_COMMAND_xx in order to be able to log in from tty1... brb | |
| 07:19 | alkisg has left IRC (alkisg!~alkisg@plinet.ioa.sch.gr, Remote host closed the connection) | |
| 07:20 | work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr) | |
| 07:20 | work_alkisg is now known as alkisg | |
| 07:26 | Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13) | |
| 07:33 | <alkisg> vagrantc: you should package the example ltsp-session in libpam-sshauth's examples...
| |
| 07:49 | Ah and since we'll be using libpam_sshauth, there's no reason to delete the tty1 service, it's useful now
| |
| 07:50 | <vagrantc> you'll have to configure it, but sure
| |
| 07:51 | it's got it's own package at the moment
| |
| 07:51 | <alkisg> vagrantc: which file do we need to configure? /etc/pam.d/login?
| |
| 07:51 | <vagrantc> yeah
| |
| 07:51 | <alkisg> (09:51:13 πμ) vagrantc: it's got it's own package at the moment => /me didn't get that, are you talking about libpam-sshauth?
| |
| 07:52 | That's what I installed, but it didn't contain /usr/bin/ltsp-session...
| |
| 07:52 | Or at least /usr/share/examples/...ltsp-session
| |
| 07:52 | Ah, are you thinking that we should ship /usr/bin/ltsp-session from the ltsp package?
| |
| 07:53 | Instead of symlinking it from init-ltsp.d?
| |
| 07:54 | <vagrantc> http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes
| |
| 07:54 | ltsp-pam-examples
| |
| 07:55 | i just install the init-ltsp.d hook as part of ltsp-pam
| |
| 07:55 | <alkisg> whoops, I didn't install libnss-extrausers... thanks for the link
| |
| 07:56 | <vagrantc> well, the ltsp-pam package handles that stuff :)
| |
| 07:56 | in the current progress section
| |
| 08:00 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 08:02 | <alkisg> vagrantc: in ltsp-pnp, we don't want to modify the server's nss/pam configuration, we want to do those dynamically from init-ltsp.d
| |
| 08:02 | Dunno if that affects any of the current ltsp-pam scripts...
| |
| 08:02 | <vagrantc> i think the ltsp-pam package does everything from init-ltsp.d
| |
| 08:02 | or at least it should
| |
| 08:03 | <alkisg> Cool
| |
| 08:03 | <vagrantc> long-term, it should be integrated directly into ltsp.
| |
| 08:07 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 240 seconds) | |
| 08:27 | nocturn00 has left IRC (nocturn00!~nocturn@85.234.217.236.static.edpnet.net, Ping timeout: 245 seconds) | |
| 08:32 | nocturn has joined IRC (nocturn!~nocturn@unaffiliated/nocturn) | |
| 08:41 | <alkisg> vagrantc: why in pam.d/lightdm, and not in common?
| |
| 08:41 | So that it works for tty's too?
| |
| 08:41 | <vagrantc> alkisg: caution
| |
| 08:41 | alkisg: i.e. you might only want to selectively allow certain services
| |
| 08:41 | <alkisg> ok... I copied lightdm to pam.d/login, but a tty login then got stuck in "calling /usr/share/ltsp-pam/ltsp-sesison"...
| |
| 08:42 | ...after after 1 minute, FAILED LOGIN for guest: system error
| |
| 08:42 | * alkisg digs more... | |
| 08:43 | <vagrantc> there are probably some parts of that code that aren't meant to be run from arbitrary pam sessions
| |
| 08:44 | <alkisg> OK let me see if it works from lightdm, first
| |
| 08:54 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 09:04 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 245 seconds) | |
| 09:05 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
| 09:09 | Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 246 seconds) | |
| 10:11 | Fenuks has joined IRC (Fenuks!~Fenuks@5.128.82.13) | |
| 10:26 | workingcats has joined IRC (workingcats!~workingca@212.122.48.77) | |
| 10:28 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Read error: Connection reset by peer) | |
| 10:29 | cyberorg has joined IRC (cyberorg!~cyberorg@203.187.194.152) | |
| 10:29 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 10:47 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 10:47 | hachque has left IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060, Remote host closed the connection) | |
| 10:51 | hachque has joined IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060) | |
| 11:33 | Fenuks has left IRC (Fenuks!~Fenuks@5.128.82.13, Ping timeout: 264 seconds) | |
| 11:34 | GrembleBean has joined IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net) | |
| 12:22 | Yiannis_ has joined IRC (Yiannis_!c23fefeb@gateway/web/freenode/ip.194.63.239.235) | |
| 12:23 | <Yiannis_> alkisg
| |
| 12:23 | @alkisg
| |
| 12:27 | Yiannis_ has left IRC (Yiannis_!c23fefeb@gateway/web/freenode/ip.194.63.239.235, Client Quit) | |
| 12:27 | <elias_a> Yiannis_: He has fallen asleep ;-)
| |
| 12:28 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
| 12:31 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Client Quit) | |
| 13:32 | alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg) | |
| 13:56 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 250 seconds) | |
| 13:57 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 13:58 | <alkisg1> cyberorg: congrats about the release ;)
| |
| 14:05 | <cyberorg> alkisg1, thanks :)
| |
| 14:10 | gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, Remote host closed the connection) | |
| 15:03 | mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Ping timeout: 257 seconds) | |
| 15:15 | mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au) | |
| 15:25 | sbalneav1 has left IRC (sbalneav1!~sbalneav@mail.legalaid.mb.ca, Quit: WeeChat 0.3.8) | |
| 15:25 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 15:25 | sbalneav has joined IRC (sbalneav!~sbalneav@mail.legalaid.mb.ca) | |
| 15:35 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 15:36 | vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi) | |
| 15:37 | Fenuks has joined IRC (Fenuks!~Fenuks@212.20.39.215) | |
| 15:39 | <vmlintu> alkisg: alkisg1: I just noticed from the logs that you've been discussing guest logins. I just did a new thin client guest login implementation for our systems last weekend..
| |
| 15:42 | There's a inetd listener on the ltsp server that listens for connections from the thinclients. The thinclient uses nc to send the username to the ltsp server and it has to be of form guest-<hostname>.
| |
| 15:42 | inetd then runs a script that creates a user on the ltspserver the same way as lightdm does:
| |
| 15:42 | https://github.com/opinsys/puavo-ltsp/blob/thinguest/client/puavo-ltspserver-create-guest
| |
| 15:43 | that script is still missing a check that the hostname actually exists before creating the user
| |
| 15:44 | Then there's an additional ltspguestsshd running that has a PAM stack that allows users to login without password.
| |
| 15:44 | https://github.com/opinsys/puavo-ltsp/blob/thinguest/client/templates/etc/pam.d/ltspguestsshd
| |
| 15:45 | ltspserver-guest-login checks that the username is of form guest-<remote hostname> and let's the user login if it matches:
| |
| 15:45 | https://github.com/opinsys/puavo-ltsp/blob/thinguest/client/pam/ltspserver-guest-login
| |
| 15:46 | If you run ssh with option -o NumberOfPasswordPrompts=0, it logs in without a password without using keys or anything else..
| |
| 15:48 | The code is not in actual use yet, so there are probably some issues still..
| |
| 15:49 | My ltsp servers are now pxe booting themselves using the same image as the clients, so the code has some quirks for that too..
| |
| 16:52 | <alkisg1> vmlintu: cool! I don't know where in the logs you saw that, but for "real" guest logins here I'm just creating a local user and using an nbd swap mount from the server, formatted as ext4, for /home/guest...
| |
| 16:53 | I.e. there's no ssh/sshfs to the server involved at all
| |
| 16:54 | Fenuks|2 has joined IRC (Fenuks|2!~Fenuks@212.20.39.215) | |
| 16:57 | <vmlintu> alkisg1: that's for fatclients?
| |
| 16:58 | <alkisg1> Yup, although for thin clients you'd need server-side users as you said, ok
| |
| 16:59 | <vmlintu> yes, for fat clients I'm using pretty much the normal lightdm guest session like you do
| |
| 17:01 | Fat clients are much easier for guest logins.
| |
| 17:05 | On normal ltsp servers one can of course create the guest users once when setting it up
| |
| 17:08 | I haven't been following lately - is lightdm out of the picture now?
| |
| 17:09 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 17:13 | <alkisg1> vmlintu: I think we've decided that we don't want to rip out ldm and start clean with ltsp6, but to progressively implement stuff _before_ removing ldm, so that then replacing ldm with lightdm is a much smaller task than it is now
| |
| 17:15 | GrembleBean has left IRC (GrembleBean!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave) | |
| 17:34 | Fenuks|2 has left IRC (Fenuks|2!~Fenuks@212.20.39.215, Ping timeout: 245 seconds) | |
| 18:05 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 264 seconds) | |
| 18:05 | Fenuks has left IRC (Fenuks!~Fenuks@212.20.39.215, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) | |
| 18:05 | ogra_ has joined IRC (ogra_!~ogra_@80.152.237.3) | |
| 18:10 | ogra_ has left IRC (ogra_!~ogra_@80.152.237.3, Max SendQ exceeded) | |
| 18:11 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 18:16 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 18:21 | alkisg is now known as work_alkisg | |
| 18:21 | alkisg1 is now known as alkisg | |
| 18:47 | workingcats has left IRC (workingcats!~workingca@212.122.48.77, Quit: Leaving) | |
| 18:59 | kev_j has joined IRC (kev_j!~Kevin@web.ta-realty.com) | |
| 19:18 | kev_j has left IRC (kev_j!~Kevin@web.ta-realty.com, Quit: Leaving) | |
| 19:46 | ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 252 seconds) | |
| 20:41 | monteslu has left IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net, Ping timeout: 240 seconds) | |
| 20:45 | monteslu has joined IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net) | |
| 21:19 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 21:42 | 36DABZBHP <36DABZBHP!~egorij@91.210.103.30> has joined #ltsp | |
| 21:46 | 36DABZBHP <36DABZBHP!~egorij@91.210.103.30> has quit IRC (K-Lined) | |
| 21:52 | shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Remote host closed the connection) | |
| 21:57 | shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers) | |
| 22:01 | vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 250 seconds) | |
| 22:07 | brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-dirbgtgicrovmwjn, Quit: Leaving.) | |
| 22:18 | <other_other_joe> anyone ever try something like profile-sync-daemon on a fat client setup?
| |
| 22:18 | I'm seeing tons of nfs writes all due to the browser profiles
| |
| 22:19 | I think if I can keep them local things'll be much more snappy
| |
| 22:32 | hkfrvuwzbz has joined IRC (hkfrvuwzbz!iamparadox@c-71-206-130-134.hsd1.va.comcast.net) | |
| 22:35 | |Paradox| has left IRC (|Paradox|!~iamparado@c-71-206-130-134.hsd1.va.comcast.net, Ping timeout: 245 seconds) | |
| 22:36 | hkfrvuwzbz is now known as |Paradox| | |
| 22:49 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 23:43 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |