I'm sure that you are aware that LVM will do snapshots as well? Maybe this
can be used to avoid the reboot?

The simplicity of not having to chroot into the LTSP client filesystem
would be a welcome change in general. I run a 10-client environment, so I
think I am your target audience.

Even if sensitive server files bleed over to the client image, doesn't
Ubuntu's security settings block other users anyway?

Thanks for all of the work!

On Mon, Apr 2, 2012 at 3:16 AM, Alkis Georgopoulos <alk...@gmail.com> wrote:

> Στις 02/04/2012 09:55 πμ, ο/η David Burgess έγραψε:
> > This is the first I've heard of this, so please excuse my ignorance.
> > Is this going to be the single method going forward or will do you
> > plan to preserve the old way for some foreseeable future?
>
> This package will only be available in a PPA. It's not related to
> ltsp-upstream and won't be included in any distros for a long time, and
> certainly not until any security concerns are resolved.
> And even then, it will be just an "alternative way to maintain LTSP",
> not "the new way to maintain LTSP".
>
>
> > I admin a network of 80 or so thin clients that all use LTSP to boot
> > and run RDP, so here are my concerns with the new system you're
> > describing.
>
> The target user group is small computer labs where a simple GUI-based
> method to maintain a Linux fat chroot is preferred over the
> console-based one.
> Since you're using RDP, you definately don't need it, so you can
> completely ignore the related mails.
>
>
>  > My second concern is comparatively minor. I would really hate to have
>  > to reboot with every image update though, as things tend to happen
>  > here in a day at work, and it sure is nice to be able to tweak
>  > something on the fly and not have to bring everybody down.
>
> That's why it targets small computer labs, where it's not a very big
> problem to reboot the server at the end of the day if an image update is
> necessary.
> Actually one could do that when the server is running too; but he's
> risking filesystem and package inconsistencies if he's installing
> programs etc while running the export image script.
> In the future, when a compressed BTRFS file system will be an option for
> LTSP servers, there won't be a need for a server reboot as it will be
> possible to use BTRFS snapshots. With those, there won't even be a
> squashfs step necessary, the image exporting will be instant.
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _____________________________________________________________________
> Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
>      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help,   try #ltsp channel on irc.freenode.net
>



-- 
Jay Goldberg
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to