Bug 462228 - ltsp-client MUST NOT be installed on the server
ltsp-client MUST NOT be installed on the server
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ltsp (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
Fedora Extras Quality Assurance
:
: 462993 DanT (view as bug list)
Depends On:
Blocks: K12LTSP
  Show dependency treegraph
 
Reported: 2008-09-14 11:35 EDT by John Ellson
Modified: 2008-10-24 06:33 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-24 06:33:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ltsp.spec changes (2.59 KB, patch)
2008-09-14 22:26 EDT, John Ellson
no flags Details | Diff
change to cp mkinitrd on client only (467 bytes, patch)
2008-09-14 22:27 EDT, John Ellson
no flags Details | Diff
fix for breakage to: ltsp-client-build --arch=x86_64 (552 bytes, patch)
2008-09-14 22:28 EDT, John Ellson
no flags Details | Diff

  None (edit)
Description John Ellson 2008-09-14 11:35:50 EDT
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 19:28:12 EDT
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 19:35:32 EDT
And yes, warnings should be added to the description of the ltsp-client package.
Comment 3 John Ellson 2008-09-14 22:25:44 EDT
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-14 22:26:43 EDT
Created attachment 316707 [details]
ltsp.spec changes
Comment 5 John Ellson 2008-09-14 22:27:42 EDT
Created attachment 316708 [details]
change to cp mkinitrd on client only
Comment 6 John Ellson 2008-09-14 22:28:46 EDT
Created attachment 316709 [details]
fix for breakage to: ltsp-client-build --arch=x86_64
Comment 7 Ugo Viti 2008-09-24 15:24:22 EDT
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 14:39:23 EDT
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 15:24:07 EDT
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 15:27:29 EDT
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 19:59:08 EDT
I used basically your approach with slight changes.  Will be released in ltsp-5.1.25.
Comment 12 Axel Thimm 2008-10-11 03:20:26 EDT
*** Bug 462993 has been marked as a duplicate of this bug. ***
Comment 13 Chuck Ebbert 2008-10-23 22:38:44 EDT
*** Bug 465132 has been marked as a duplicate of this bug. ***
Comment 14 Warren Togami 2008-10-24 06:33:51 EDT
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.