Bug 234048 - LTSP 5 support needed
Summary: LTSP 5 support needed
Keywords:
Status: CLOSED DUPLICATE of bug 188611
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 7
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Bill Nottingham
URL: http://wiki.ltsp.org/twiki/bin/view/L...
Whiteboard:
Depends On: K12LTSP
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-26 19:42 UTC by Jari Turkia
Modified: 2014-03-17 03:06 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-05-16 20:59:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jari Turkia 2007-03-26 19:42:00 UTC
Description of problem:
LTSP in version 5 has been completely rewritten and requires Fedora to support
LTSP directly.

Version-Release number of selected component (if applicable):
-

How reproducible:
always

Steps to Reproduce:
1. install Fedora Core 6
2. attempt to get LTSP 5 running
3.
  
Actual results:
Cannot get LTSP 5 running.

Expected results:
A working LTSP 5

Additional info:

Comment 1 Phil Knirsch 2007-05-24 15:19:55 UTC
Reassigning to distribution.

Read ya, Phil

Comment 2 Jesse Keating 2007-05-24 15:35:29 UTC
Erm... I'm going to need a few more details about what you expect to happen with
this bug...

Comment 3 Jari Turkia 2007-05-24 15:54:37 UTC
I'd like Fedora to support LTSP so that clients running over network would
execute a Fedora installation.

See: http://wiki.ltsp.org/twiki/bin/view/Ltsp/DownLoads
"Ltsp-5 on Other distributions
Our goal is for all distros to provide LTSP integration."

What I'm asking here is the Fedora LTSP integration. I'm assuming that you know
what LTSP is and what it is used for. So, what is needed is a chrooted
installation of Fedora inside a Fedora installation. To be clear: this chrooted
installation need not to be run by the host computer, but need to be accessed by
the LTSP-clients. This is not a virtualization case.

Basically it boils down to two things:
1) booting over network: PXE or etherboot loaded kernel+InitRD needs to activate
a NIC and mount a NFS-root to access rest of the distro
2) package management: both the host installation and LTSP installation need
updates!

All this cannot be achieved without direct support and participation from Fedora
project.

Comment 4 Jesse Keating 2007-05-24 16:04:05 UTC
But what does "support" mean?  You can create chroots in Fedora, you can use yum
in chroots to update the chroot, you can use yum outside the chroot to update
the host.  I'm not sure what's "missing" that you need "support" for.

Comment 5 Jari Turkia 2007-05-24 16:16:54 UTC
Ok. Where is this chroot-installation documented?

In the LTSP wiki there is a page regarding distro integration:
http://wiki.ltsp.org/twiki/bin/view/Ltsp/IntegratingLtsp

Also, that does not solve the booting. Basic assumption is that a thin-client
does not have any storage space in it and default InitRD does not survive the
NFS-root -scenario.

In order to get a thin-client booting properly, you need to load the client
configuration. For this LTSP provides a framework. What would be nice to have is
a Fedora RPMs of that.

Does that clarify the situation?

Comment 6 Jesse Keating 2007-05-24 16:19:23 UTC
Well, mock can be used to create a chroot of packages, or yum could generically
with --installroot options.  Maybe what's missing is some easy to use
application to do it for you.

It doesn't clarify much, but given that Fedora is open to the community and
anybody can bring new packages in, what's stopping you from creating said
packages and going through the review process to get the package in Fedora?

Comment 7 Ken Tanzer 2007-05-24 16:28:35 UTC
My understanding is that this goes beyond just Fedora in a chroot. LTSP support
would invole having transparent support for sound, local devices, printers, etc.
on the thin clients (user workstations). Apparently ubuntu is the farthest along
with integrating LTSP support into the distribution. Although I didn't get it
running, I took a quick look at Ubuntu, and the general idea seems to be that
you install some LTSP packages, and then run a binary or script to build the
chroot environment.

FWIW, and in case you're not familiar with LTSP, it's a really great program (we
run approximately 180 workstations from a few LTSP servers), and getting support
for it integrated into Fedora would be fantastic.  We currently use LTSP 4.2,
which is the last version done before switching to the "integrate with
distributions" strategy.  It works really well, but LTSP 5 would bring much
better sound & device support.  



Comment 8 Jesse Keating 2007-05-24 16:47:32 UTC
I'm fully aware of what LTSP is.  However just saying generically "Fedora needs
support for it" doesn't help at all.  What specifically is needed from which
parts of software?  Each part should get the individual feature request to be
handled.  And if Ubuntu were being a good OSS citizen, their changes would be
going upstream and everybody would benefit from them.

Comment 9 Jari Turkia 2007-05-24 18:09:04 UTC
(In reply to comment #8)
> I'm fully aware of what LTSP is.  However just saying generically "Fedora needs
> support for it" doesn't help at all.  What specifically is needed from which
> parts of software?  Each part should get the individual feature request to be
> handled.

There seems to be a Grand Canyon sized gap between us.

I, for example, do not have enough knowledge about Fedora's details to break the
request down into individual feature requests. To my understanding a group
effort involving various parts of Fedora is required anyway. That's where your
and Fedora Project's help is required to get LTSP supported.

Mock-package seems promising. Is there documentation or somebody to contact
regarding init ram-disk? My guess is that default kernel would do the trick if a
proper InitRD would be present. That combined with something mock-ish would be a
step to the right direction.

Comment 10 Jesse Keating 2007-05-24 18:27:11 UTC
Bugzilla is horrible for this.  Please start a conversation on
fedora-devel-list so that more interested parties can chime in and
start fleshing out what it is that is needed of Fedora.

Comment 11 Patrice Dumas 2008-01-05 09:47:30 UTC
You can have a look at
Bug 234048

Comment 12 Patrice Dumas 2008-01-05 09:49:29 UTC
Crap, I meant look at Bug 188611

Comment 13 Bug Zapper 2008-05-14 12:11:23 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 14 Bill Nottingham 2008-05-16 20:59:27 UTC

*** This bug has been marked as a duplicate of 188611 ***


Note You need to log in before you can comment on or make changes to this bug.