Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 462228 - ltsp-client MUST NOT be installed on the server
Summary: ltsp-client MUST NOT be installed on the server
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ltsp
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Warren Togami
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 462993 DanT (view as bug list)
Depends On:
Blocks: K12LTSP
TreeView+ depends on / blocked
 
Reported: 2008-09-14 15:35 UTC by John Ellson
Modified: 2008-10-24 10:33 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-24 10:33:51 UTC


Attachments (Terms of Use)
ltsp.spec changes (deleted)
2008-09-15 02:26 UTC, John Ellson
no flags Details | Diff
change to cp mkinitrd on client only (deleted)
2008-09-15 02:27 UTC, John Ellson
no flags Details | Diff
fix for breakage to: ltsp-client-build --arch=x86_64 (deleted)
2008-09-15 02:28 UTC, John Ellson
no flags Details | Diff

Description John Ellson 2008-09-14 15:35:50 UTC
Description of problem:
If ltsp-client is mistakenly installed on the ltsp server (or any, non ltsp-client host) it silently modifies the behavior of mkinitrd such that future upgrades of the kernel will fail - e.g.by trying to mount root via NFS.

Minimally the desription returned from "yum --info ltsp-client" should provide loud and clear warnings.

Better would be for ltsp-client to refuse to install if it is not being installed into an ltsp chrooted image.

Version-Release number of selected component (if applicable):
ltsp-client-5.1.24-1.fc10

How reproducible:
100%

Steps to Reproduce:
1. on a regular fedora box, yum install ltsp-client
2.
3.
  
Actual results:
future kernel upgrades fail by looking for root over nfs

Expected results:
Should not be possible to install ltsp-client on the server.

Additional info:

Comment 1 Warren Togami 2008-09-14 23:28:12 UTC
Nice catch!  I tried to guard against damage like this by checking for /etc/ltsp_chroot in other places, but I forgot about the /etc/sysconfig/mkinitrd file that it began dropping in the filesystem recently.

Here is what I'm thinking we should do:

1) ltsp-client must not ship any /etc/sysconfig/mkinitrd.  I am not sure if we should simply ship nothing at that path, or %ghost it.  I am leaning toward nothing, because then it wouldn't accidentally remove a config file left by someone else when you remove ltsp-client.
2) %post of ltsp-client should check for the existence of /etc/ltsp_chroot.  If it does exist, copy and forcefully overwrite whatever is already at /etc/sysconfig/mkinitrd.  ltsp-client already runs ltsp-chroot-setup during %post so this can be easily added to the existing plugins of chroot-setup.
3) ltsp-trunk/server/scripts/k12linux/chroot-creator already creates /etc/ltsp_chroot before the RPMS are installed in the chroot, so we are covered here.

Could you please test this plan?  I am going into surgery tomorrow so things will be a bit rough for me for a while.

We definitely must fix this before K12Linux LTSP Terminal Server F9 Beta 2.

Comment 2 Warren Togami 2008-09-14 23:35:32 UTC
And yes, warnings should be added to the description of the ltsp-client package.

Comment 3 John Ellson 2008-09-15 02:25:44 UTC
I'll attach the 3 proposed patches here.   The two bzr changes can be pulled from http://john.ellson.com/ltsp-ellson/

The first two patches fix this bug:

1. cvs patch to: devel/ltsp.spec

2. bzr patch to: client/chroot-setup/k12linux/030-configure-client


The third patch fixes a problem with:  ltsp-client-build --arch=x86_64
that I encountered during testing. (It was reverting to i386)

3. bzr patch to: server/plugins/ltsp-build-client/common/001-set-arch

Comment 4 John Ellson 2008-09-15 02:26:43 UTC
Created attachment 316707 [details]
ltsp.spec changes

Comment 5 John Ellson 2008-09-15 02:27:42 UTC
Created attachment 316708 [details]
change to cp mkinitrd on client only

Comment 6 John Ellson 2008-09-15 02:28:46 UTC
Created attachment 316709 [details]
fix for breakage to: ltsp-client-build --arch=x86_64

Comment 7 Ugo Viti 2008-09-24 19:24:22 UTC
Hi,

I confirm this behaviour, I spent last hour figuring out because after kernel upgrade (from 2.6.25 to 2.6.26) my server can't boot any more and because initrd was so bigger respect my working initrd :-)

parsed /sbin/mkinitrd script and discovered that mkinird read /etc/sysconfig/mkinitrd, rpm -qif /etc/sysconfig/mkinitrd discovered that was owned by ltsp-client.

this solved the problem:

rpm -e ltsp-client
mkinitrd -f /boot/initrd-2.6.26.3-29.fc9.i686.PAE.img 2.6.26.3-29.fc9.i686.PAE


A better fix could be to write ltsp-client mkinitrd config to /etc/sysconfig/mkinitrd.ltsp and change the update kernel scripts for ltsp clients with extra parameters providing the correct path of ltsp mkinitrd config file?

I think this must be a priority update, because inadvertently installing ltsp-client can render unbootable the system.

Best Regards

Comment 8 Warren Togami 2008-09-25 18:39:23 UTC
I agree that this must be fixed soon.  I have been in rough shape lately recovering from major surgery.  I will make sure this is fixed soon.

To be clear however, why are you installing ltsp-client on a non-LTSP system?

Comment 9 John Ellson 2008-09-25 19:24:07 UTC
Welcome back Warren.  Hope your recovery is going well.

Let me know if I can do anything to help with this.

Regarding your clarification, arguably an LTSP-server is an LTSP-system ;-)

Comment 10 Warren Togami 2008-09-28 19:27:29 UTC
John, I have reviewed your patches.

--- server/plugins/ltsp-build-client/common/001-set-arch	2008-02-12 12:09:37 +0000
+++ server/plugins/ltsp-build-client/common/001-set-arch	2008-09-15 01:50:44 +0000
@@ -36,7 +36,7 @@
             x86_64|amd64)
             case "$(uname -m)" in
                 x86_64)
-                ARCH=amd64
+                ARCH=x86_64

common/001-set-arch is not used by any distribution.  Everyone supplies their own 001-set-arch to override the common plugin because it is too flawed.  It is possible that there remains a problem in our Fedora/001-set-arch, but it needs to be fixed there if so.

--- client/chroot-setup/k12linux/030-configure-client	2008-08-21 17:19:13 +0000
+++ client/chroot-setup/k12linux/030-configure-client	2008-09-15 01:47:25 +0000
@@ -49,3 +49,6 @@
 
 # TEMPORARY: /var/lib/pulse/ must exist (we can remove this soon)
 mkdir -p /var/lib/pulse/
+
+# install /etc/sysconfig/mkinitd for client kernel upgrades
+cp -f /etc/sysconfig/ltsp-mkinitrd /etc/sysconfig/mkinitrd

This shouldn't be necessary during ltsp-build-client time, but perhaps we will use it anyway because we want to override whatever is in /etc/sysconfig/mkinitrd in the case of upgrading to a newer version of ltsp-client.

Comment 11 Warren Togami 2008-10-05 23:59:08 UTC
I used basically your approach with slight changes.  Will be released in ltsp-5.1.25.

Comment 12 Axel Thimm 2008-10-11 07:20:26 UTC
*** Bug 462993 has been marked as a duplicate of this bug. ***

Comment 13 Chuck Ebbert 2008-10-24 02:38:44 UTC
*** Bug 465132 has been marked as a duplicate of this bug. ***

Comment 14 Warren Togami 2008-10-24 10:33:51 UTC
This was fixed in ltsp-5.1.26-1.fc9 in F9 updates for a while now.


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