Bug 331731

I have various problems when trying to test that
package (source0 instead of source4, wrong files list).
Is there a version that can be built?

Also maybe there are duplicate bits with system-config-netboot,
this package should certainly be taken into account.

It builds a little better when I remember to push my local repository...

Spec URL:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server-config/ltsp-server-config.spec
SRPM URL:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server-config/ltsp-server-config-0-2.fc8.src.rpm

as per comments in https://bugzilla.redhat.com/show_bug.cgi?id=330921
created a new branch which includes ltsp-dhcpd configurations.

Spec URL:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server-config-with-dhcp/ltsp-server-config.spec
SRPM URL:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server-config-with-dhcp/ltsp-server-config-0-3.fc8.src.rpm

It would be much better, in my opinion, to unpack the
archive in %prep and then do a cp -a in %install. That
way it is possible to look at the archive content and 
also do corrections (patches, moving things around),
it is especially importantn for people wanting to customize 
their system.

I also propose to put things in the directory making use of 
the rpm macros.

I post a patch.

Created attachment 228351 [details]
unpack in build directory and honor macros

Created attachment 228381 [details]
in ltsp-swapfile-delete add a variable for swap directory

This allows to modify easily the directory with a sed
command (for example using rpm macros, but not only). 

I also changed the shebang since this script seems
to be perfect sh to me.

In ltsp-swapfile-delete, I think it would be better
to use
netstat -natup 
to avoid listing the unix domain sockets.

Missing related requires:

tmpwatch iputils (or /bin/ping) and net-tools 
(or /bin/netstat).

For iptables, I think that it would be much better to interact
with the iptables maintainer such that he modifies the main
iptables script such that

* it honors TRUSTED_ETH
* it sources /etc/sysconfig/$IPTABLES-ltsp if the file exists

ltspfs-insecure should be a config script to be run by the admin
(or part of the main cionfig script) and not an init script.

init.d/ltsp-swapfile-delete shouldn't be automatically started
since there is already the cron.daily script that should take care
of stale files, and therefore the choice should be left to the
user.

The READMES should be in %doc.

ltsp-initialize should be in %_bindir.

I propose adding an /etc/sysconfig/ltsp5 file with 

LTSP_DEV="eth0"
LTSP_DEFAULTIP="192.168.0.254"
LTSP_DEFAULTMASK="255.255.255.0"

and source it in the beginning of ltsp-initialize.

It seems to me that ltsp-dhcpd.conf should be taken from
/usr/share/ltsp5/ by dhcpd-update if there is no 
/etc/ltsp-dhcpd.conf file, that way nothing would be
installed prior from ltsp-initialize being called.
This would solve the generality issue I pointed out
in the ltsp-dhcp review. In that case the comment
in spec file should be shortened.

it would be nice to provide scripts like those used
for other display managers for the 2 other dm of fedora
wdm and slim. Not a blocker, and certainly a job for
the dm packagers (I am the wdm packager...).

Created attachment 228421 [details]
use a variable for the ltsp dir in  exports-update for easy change

Created attachment 228431 [details]
add a variable for the ltsp dir in ltsp.conf-update for easy change

Also maybe there shouldn't be a requires for gdm, but for any
xdmcp display manager, and a virtual provides added for display
managers that have xdmcp possibilities?

Also it seems to me that ltsp-dhcpd shouldn't be enabled in the
default case, but instead the same system that for other services
should be used (in fact this is already the case, so the only 
remaining things to do are to remove the default starts).

Created attachment 229461 [details]
ltsp-swapfile-delete.patch

Comment #5 - patch applied

Comment #7 - excellent suggestion. I prefer to edit files in
        /etc/sysconfig/ rather than elsewhere in /etc/, so I changed
        this to the attached ltsp-swapfile-delete.patch

Comment #8 - applied

Comment #9 - perhaps we should suggest this as a use case for a general
        purpose enhancement, a la /etc/iptables.d/ (or does such a mechanism
        already exist? A quick search turned up nothing of interest)

Comment #10 - the LTSP client swap files are invalid if the client
        disconnects (which is guarrented to be the state if the server
        is booting up), and as such it is safe to remove all of the
        LTSP client swap files. I'm ok with letting the cron.daily script
        take care of this, but it make sense to me if they are cleared out
        when the server boots.

        Yes, I agree that it is obvious that the docs should be in %doc ;-)

        How about %_sbindir for ltsp-initialize.

        /etc/sysconfig/ltsp5 sounds good to me.

        *EXCELLENT* idea on having ltsp_initialize create /etc/ltsp-dhcpd.conf

Created attachment 229471 [details]
Comments #11 & #12, this makes more sense to me

comment 10:

if ltsp-initialize is moved to /usr/sbin/, someone is more likely to find it by
accident and run it to see what it does ("./ltsp-initialize -h" is not an
unreasonable use-case). I changed this command to require a "-y" flag, otherwise
it spits out a warning & exit 1

comment 10:

I changed /etc/rc.d/init.d/iptables-ltsp to source /etc/sysconfig/ltsp5

I'm making a lot of mistakes, so I'm stopping here. I believe all of the patches
& changes have been made, with the exception of the %doc changes. These build
and they pass rpmlint (with the previously noted exception). 

SPEC: 
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server-config/ltsp-server-config.spec
SRPMS:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server-config/ltsp-server-config-0-4.fc8.src.rpm

Is there any specific reason that configuration file is /etc/sysconfig/ltsp5 as
opposed to merely ltsp? We don't usually have version specific configuration
file names and it would be problematic for documentation if we have to change
all the references when ltsp 6 rolls out. 

(In reply to comment #18)
> comment 10:
> 
> if ltsp-initialize is moved to /usr/sbin/, someone is more likely to find it by
> accident and run it to see what it does ("./ltsp-initialize -h" is not an
> unreasonable use-case). I changed this command to require a "-y" flag, otherwise
> it spits out a warning & exit 1

Agreed, this is safer. Although in the unix philosophy you are not
meant to do mistakes, I agree that it is right.

(In reply to comment #21)
> Is there any specific reason that configuration file is /etc/sysconfig/ltsp5 as
> opposed to merely ltsp? We don't usually have version specific configuration
> file names and it would be problematic for documentation if we have to change
> all the references when ltsp 6 rolls out. 

Between ltsp releases there are lots of changes, so it is not obvious
that /etc/sysconfig/ltsp5 will be suitable for ltsp6. Currently
we support ltsp4 with ltsp-utils, and the design of ltsp5 and ltsp4
are very different. Also quite different were the design of ltsp3 and
ltsp4. And in general there are years between releases. Moreover we should
certainly maintain different ltsp releases in parallel, as long as they
are maintained upstream (currently it seems that ltsp4 and ltsp5 
are maintained).

In fact I think that we could even try to ensure that the paths
are version specific such that it will be possible to install in 
parallel ltsp5 and ltsp6. It is not obvious either, especially
for the client nfs root, but this should be considered.

Why 192.168.0.x as a default network? Why not ask a question like which net
device will the clients be attached and derive the correct network?

The server should be using static rather than dhcp addresses so the right
network configuration is in /etc/sysconfig/networking-scripts/ifcfg-ethx... or
it can be read from the output of ifconfig if it was dhcp.

Having an interface to the configuration used by ltsp5
would be nice, be it a simple shell script, a full featured
gui or a curse interface, but it seems to me that separating
configuration in text files should be the only prerequisite.

A simple shell script that sources /etc/sysconfig/ltsp5, 
proposes to change the values, rewrite the file and 
launch ltsp-initialize could be nice, but not a requirement
in my opinion.

As for eth0 being 192.168.0.x it is because it is the most
common setup (terminals in a private class C network).

Unless I am wrong, ltsp-initialize reads
/etc/sysconfig/networking-scripts/ifcfg-ethx:

        # Source the network configuration
        . /etc/sysconfig/network-scripts/ifcfg-$DEV

(In reply to comment #24)
> As for eth0 being 192.168.0.x it is because it is the most
> common setup (terminals in a private class C network).
> 
> Unless I am wrong, ltsp-initialize reads
> /etc/sysconfig/networking-scripts/ifcfg-ethx:
> 
>         # Source the network configuration
>         . /etc/sysconfig/network-scripts/ifcfg-$DEV

It'd be great if -initialize took multiple NICs/subnets into account. On larger
installations (like mine) you have more than one subnet of thin clients on more
than one NIC. Personally I'm using .0.x and .1.x but it would be nice if a
multi-NIC setup wasn't a long and involved kludge process that required you to
work around automated settings.

(In reply to comment #25)

> It'd be great if -initialize took multiple NICs/subnets into account. On larger
> installations (like mine) you have more than one subnet of thin clients on more
> than one NIC. Personally I'm using .0.x and .1.x but it would be nice if a
> multi-NIC setup wasn't a long and involved kludge process that required you to
> work around automated settings.

If you can do patches that allow multi-nic setup, I think
that'd be great, maybe they could be in the variable like

LTSP_DEV=eth1,eth2

However at some point it becomes necessary to do things 
manually, generality is not always achievable without harmful
complexity. But I guess that it should be up to Eric to
determine whether this is bloat or useful feature.

> It'd be great if -initialize took multiple NICs/subnets into account.

Our goal for now is to get the basic functionality into rawhide.  We cannot
accommodate all needs with this initial goal.  We will likely look at supporting
your case in a later step.

perl(NetAddr::IP) is automatically detected.

You can remove most of the %description, and 
README.ltsp-config-dhcp

What about putting  etc/sysconfig/ltsp5 content in 
etc/ltsp.conf? Maybe call that file etc/ltsp5.conf?
Also I suggest adding
LTSP_SWAP_DIR=
maybe depending on LTSP_DIR

In ltsp-dhcpd-create you should not use .rpmsave.
Also you should either %ghost %{sysconfdir}/ltsp-dhcpd.conf
or, even better, something along
%config(noreplace) %verify(not size mtime md5) %{sysconfdir}/ltsp-dhcpd.conf

And in general, in the scripts I don't think that using
.rpmsave is right.

No init service should be enabled by default, since they 
are enabled by ltsp-initialize.

(in reply to comment #22)

Note that thin-clients often long out-live the server. Newer versions of the
software do not always work with the older clients. The way this has been
historically dealt with was by allowing multiple versions of the LTSP software
to be installed. /opt/ltsp4/, /opt/ltsp5/, /tftpboot/ltsp5/, etc. 

(in reply to comment #23 & friends)
192.168.0.254 is the upstream LTSP default. As noted in comment #25, the scripts
will automagically change this if the network range is different. Yes, I'd love
to see this re-written & a shiny gui wrapper added. But that is not my skill
set, some else will get to do that enhancement. *cough* *cough* anyone want to
maintain a shiny new package or two?

(in reply to comment #28)
agreed that the configs should consolidated into one file. I started working on
that last night before I fizzled out. Working on it now.

SPEC: 
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server-config/ltsp-server-config.spec
SRPMS:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server-config/ltsp-server-config-0-5.fc8.src.rpm

I believe I have all of the changes applied. Now off to do functional testing.
If you are going to test these, note this bug that wtogami found today:

https://bugzilla.redhat.com/show_bug.cgi?id=336721

The services are all enabled, they shouldn't:
iptables-ltsp         ltspfs-insecure       
ltsp-dhcpd            ltsp-swapfile-delete  

For iptables, please contact the maintainer and direct him
to that report.

usr/share/ltsp5/config/ltsp-dhcpd.conf
is executable, it shouldn't.

in ltsp-dhcpd-create why cat and not cp?

ltsp-dhcpd.conf reappeared in etc/

the following directories are unowned:
/tftpboot/ltsp5/pxe/pxelinux.cfg
/tftpboot/ltsp5/pxe/

instead of the install for pxelinux.0, I suggest a ln -s, such
that the new file is used upon syslinux update.

Using /opt or /var/opt in the default case seems wrong to me. 
these directories should not be touched by the rpm, even indirectly.
In my opinion putting in /var/lib would be better.
(in /var/lib/ltsp5/swapfiles and /var/lib/ltsp5/i385...).

(in reply to comment #31)

At least iptables-ltsp (until an alternative is implemented) and ltsp-dhcpd need
to be started by default if the server is configured to boot thin clients.

I'll contact the iptables maintainer

usr/share/ltsp5/config/ltsp-dhcpd.conf fixed.

I changed ltsp-dhcpd-create to cat because I was going to make it a template and
run it through sed (i.e. cat ltsp-dhcpd.conf.template | sed s/IP/$IP/ >
/etc/ltsp-dhcpd.conf), but got side-tracked fixing other bugs.

I added an empty file in etc/ltsp-dhcpd.conf because %{ghost} & friends were
complaining that the file did not exist. I need to read up on the docs on that
one, I'm obviously doing something wrong. 

/tftpboot/ltps5/pxe fixed.

tftpd chroots into /tftpboot/, a symlink will not work.

Jim McQuillian @ LTSP contacted the LSB long ago asking for assistance on where
to place the ltsp root. They settled on /opt/.  I just checked and both Ubuntu
and Debian are currently using /opt/ for their ltsp5 implementations. I didn't
see where they are putting the swap files. I'll get to that shortly. That said,
I'm not particularly attached to /opt/, but it is nice to be consistent with
everyone else.

I just pushed out an update with a bunch of scripting fixes. I'll push out all
of the above changes here shortly.

(In reply to comment #32)
> (in reply to comment #31)
> 
> At least iptables-ltsp (until an alternative is implemented) and ltsp-dhcpd need
> to be started by default if the server is configured to boot thin clients.

But they will once the script has been run. They really shouldn't
be started at install time.

(In reply to comment #32)
> (in reply to comment #31)
> 
> I changed ltsp-dhcpd-create to cat because I was going to make it a template and
> run it through sed (i.e. cat ltsp-dhcpd.conf.template | sed s/IP/$IP/ >
> /etc/ltsp-dhcpd.conf), but got side-tracked fixing other bugs.

Ok, you can leave the cat.

> tftpd chroots into /tftpboot/, a symlink will not work.

Right. This deserves a comment in the spec file.
 
> Jim McQuillian @ LTSP contacted the LSB long ago asking for assistance on where
> to place the ltsp root. They settled on /opt/.  I just checked and both Ubuntu
> and Debian are currently using /opt/ for their ltsp5 implementations. I didn't
> see where they are putting the swap files. I'll get to that shortly. That said,
> I'm not particularly attached to /opt/, but it is nice to be consistent with
> everyone else.

I am not sure about that. I'll send a mail tomorrow to the 
packaging list.

(In reply to comment #33)
> (in reply to comment #31)
> 
> But they will once the script has been run. They really shouldn't
> be started at install time.

I have the dreadful feeling that I'm missing something ;-)

I just looked over this several times, and I don't see where they are being
started at install time. The only place that /sbin/service or /sbin/chkconfig
appears is ./usr/share/ltsp5/scripts.d/17-enable-services, which is executed by
/usr/sbin/ltsp-initialize

They have lines like:

# Default-Start: 2 3 4 5

# chkconfig: 2345 98 92

rpmlint warns about that.

(In reply to comment #32)

> Jim McQuillian @ LTSP contacted the LSB long ago asking for assistance on where
> to place the ltsp root. They settled on /opt/.  I just checked and both Ubuntu
> and Debian are currently using /opt/ for their ltsp5 implementations.

Do you have an url (or maybe you kept the mail privately)? I 
tried hard but didn't find the response of the lsb/fhs...

It was in August 2001. Most of the LSB/FHS list archives for 2001 appear to be
missing. Maybe jam still has the lsb/hfs response.

Here is part of the discussion:

http://www.redhat.com/archives/k12ltsp-list/2001-August/msg00003.html

I found that one. I'll contact Jim directly.

http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server/ltsp-server.spec
SRPMS:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server/ltsp-server-0-8.fc8.src.rpm

- make a LTSP_VERSION variable in the shell scripts
- move swap files from /var/opt/ltsp5/ to /var/lib/ltsp5/
- remove Default-Start entries from etc/init.d/*
- use TMP rather than TEMPDIR
- make sure that /etc/exports has '/opt/ltsp5 *(ro,async)', then
  we do not have to worry about the network or the client arch

- fix LTSP_SWAP_DIR path

http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server/ltsp-server.spec
SRPMS:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server/ltsp-server-0-9.fc8.src.rpm

Jim answered me and I sent a mail on the devel list.

There are comments in 
https://bugzilla.redhat.com/show_bug.cgi?id=331651
that are still not taken into account...

Regarding the %ghost, I think that it is wrong to just have it
%ghost, since if it was modified by the user it should be kept
upon removing the package, with .rpmsave. So at least it 
should be %config(noreplace).

Just a suggestion, but I find %changelogs much more
readable with an empty line between each date.

Also
ltsp-server.noarch: W: incoherent-version-in-changelog 0.9 0-9.fc8

rpmlint finds some issues in init scripts:
ltsp-server.noarch: E: no-status-entry /etc/rc.d/init.d/ltsp-swapfile-delete
ltsp-server.noarch: W: no-reload-entry /etc/rc.d/init.d/ltsp-swapfile-delete
ltsp-server.noarch: E: subsys-not-used /etc/rc.d/init.d/ltsp-swapfile-delete

Also you should add scriptlets as in:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-a6d7a1ed9d77dbb8d4af067378a79b838aebb20a

Unowned directories:
/var/lib/ltsp5/
/etc/ltsp-client/

Also maybe /etc/ltsp-client could be /etc/ltsp5/, or /etc/ltsp and other
config stuff could be in here.

* Wed Oct 17 2007 Eric Harrison <eharrison.or.us>  0.6
- typo in ltsp-initialize & gdm.conf-update
  change syslog to rsyslog

You might want to change this back to syslog, and add a conditional to the
script that handles either syslog or rsyslog depending on what is installed. 
This might allow these ltsp* packages to work on both F7 and F8.

[root@newcaprica noarch]# rpm -ivh ltsp-server-config-0-6.fc8.noarch.rpm --nodeps
Preparing...                ########################################### [100%]
        file /etc/cron.daily/ltsp-swapfile-delete from install of
ltsp-server-config-0-6.fc8 conflicts with file from package ltsp-server-0-9.fc8
        file /etc/ltsp5.conf from install of ltsp-server-config-0-6.fc8
conflicts with file from package ltsp-server-0-9.fc8
        file /etc/rc.d/init.d/iptables-ltsp from install of
ltsp-server-config-0-6.fc8 conflicts with file from package ltsp-server-0-9.fc8
        file /etc/rc.d/init.d/ltsp-dhcpd from install of
ltsp-server-config-0-6.fc8 conflicts with file from package ltsp-server-0-9.fc8
        file /etc/rc.d/init.d/ltsp-swapfile-delete from install of
ltsp-server-config-0-6.fc8 conflicts with file from package ltsp-server-0-9.fc8
        file /etc/rc.d/init.d/ltspfs-insecure from install of
ltsp-server-config-0-6.fc8 conflicts with file from package ltsp-server-0-9.fc8
        file /usr/sbin/ltsp-initialize from install of
ltsp-server-config-0-6.fc8 conflicts with file from package ltsp-server-0-9.fc8


Huh?  Was this packaged merged into ltsp-server?  Only ltsp-server-utils was
mentioned in the changelog of ltsp-server.

*** Bug 331651 has been marked as a duplicate of this bug. ***

Looks like we are getting out of sync. I closed #331651 as a dup, since most of
the comments are on this bz#.

rpm -e ltsp-server-config ltsp-server-utils

(in reply to comment #42)
- changed ltsp-dhcpd startup priority to 98 so that it runs after kvm
  (https://bugzilla.redhat.com/show_bug.cgi?id=331651)
-%ghost changed back to a %config(noreplace)
- version numbers fixed in changelog
- remove %%{_initrddir}/ltsp-swapfile-delete - after additional testing I do not
believe this is needed
- added scriptlets
- fixed /var/lib/ltsp5/
- renamed /etc/ltsp5.conf /etc/ltsp5/ltsp.conf, moved all config files to
/etc/ltsp5 --- /etc/ltsp5/ is consistent with /opt/ltsp5, /usr/share/ltsp5, etc


(in reply to comment #43)
- handle either syslog or rsyslog



http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server/ltsp-server.spec
SRPMS:
http://k12linux.mesd.k12.or.us/K12LTSP/source/ltsp-server/ltsp-server-0-10.fc8.src.rpm

Here's an interesting problem:

mknbi's purpose is to build network bootable BOOTP images out of kernel and
initrd files.  This is only usable to boot i386 clients.

ltsp-server Requires mknbi
mknbi only builds on i386 and x86_64.  But (if it were built and installed)
could mknbi's perl scripts actually work on a ppc host to connect the i386
binaries together?

Perhaps this isn't worth it, and instead we should exclude the Requires mknbi
dep on all but i386 and x86_64 archs.  Thoughts?

This addition to the ltsp-dhcpd.conf template allows it to PXE boot a qemu
guest, which reports "Etherboot-5.4" as its vendor-class-identifier.

--- ltsp-dhcpd.conf.orig        2007-10-30 02:29:16.000000000 -0400
+++ ltsp-dhcpd.conf     2007-10-30 02:31:07.000000000 -0400
@@ -43,6 +43,13 @@
         # NOTE: kernels are specified in /tftpboot/ltsp5/pxe/pxelinux.cfg/
         filename      "/ltsp5/pxe/pxelinux.0";
      } 
+     # Etherboot PXE
+     # NOTE: Oct 30th 2007: Not well tested, works with qemu kvm-36
+     elsif substring (option vendor-class-identifier, 0, 9) = "Etherboot" 
+     {
+        # NOTE: kernels are specified in /tftpboot/ltsp5/pxe/pxelinux.cfg/
+        filename      "/ltsp5/pxe/pxelinux.0";
+     } 
      # default to an i386 BOOTP image
      else 
      {

This fixes the path given to nash's mount so that it actually works.

--- ltsp.conf.orig      2007-10-30 18:14:22.000000000 -0400
+++ ltsp.conf   2007-10-30 18:14:37.000000000 -0400
@@ -27,7 +27,7 @@
 LTSP_KICKSTART=/etc/ltsp5/ltsp-build-client-ks.cfg
 
 # where to fetch ltsp kernels & where to install them
-LTSP_NFSROOT=$LTSP_DEFAULTIP/$LTSP_ROOTPATH
+LTSP_NFSROOT=$LTSP_DEFAULTIP:$LTSP_ROOTPATH
 LTSP_BOOTDIR=/tftpboot/$LTSP_VERSION
 LTSP_PXEDIR=$LTSP_BOOTDIR/pxe

Regarding mknbi, I talked briefly with dwmw2 today regarding PPC
cross-compiling.  Currently we don't ship any gcc cross-compile capable
packages.  This combined with the fact that you cannot directly install a i386
chroot on ppc, we shouldn't worry about mknbi for now.

Please use this for the mknbi dependency.

%ifarch i386 x86_64
Requires: mknbi
%endif

- Refuse to install the chroot with anaconda if selinux is enforcing.
- Remove rpmdb locks after anaconda is done installing.

--- ltsp-build-client.orig      2007-10-30 18:37:45.000000000 -0400
+++ ltsp-build-client   2007-10-30 18:52:46.000000000 -0400
@@ -32,6 +32,15 @@
    esac
 done
 
+# Anaconda chroot install will fail if selinux is enforcing
+# we need to port the workaround from mock...
+if [ -a /usr/sbin/getenforce ]; then
+   if [ `/usr/sbin/getenforce` == "Enforcing" ]; then
+      echo "ERROR: Cannot anaconda install chroot while SELinux is enforcing."
+      echo "Please use 'setenforce 0'"
+      echo "Do not forget to enable it after anaconda is done."
+   fi
+fi
 
 if [ "$LTSP_ROOTPATH" ]; then
    mkdir -p $LTSP_ROOTPATH ||  echo "ERROR: could not create directory
$LTSP_ROOTPATH";
@@ -43,3 +52,5 @@
        --rootpath $LTSP_ROOTPATH --kickstart=$LTSP_KICKSTART
 fi
 
+# remove locks: i386 chroot install on x86_64 would have incompatible locks
+rm -f $LTSP_ROOTPATH/var/lib/rpm/__db*

Created attachment 243871 [details]
minor fixes for ltsp-initialize

Created attachment 243881 [details]
very minor patch for 02-ltsp-dhcpd-create

in 06-xdm-config-update it should certainly be 
/etc/X11/xdm/xdm-config instead of /etc/X11/xdm/Xaccess

The occurence of /etc/ltsp-dhcpd.conf in 02-ltsp-dhcpd-create
should certainly be changed to 
/etc/ltsp5/ltsp-dhcpd.conf

Hi Patrice,

I'm setting up a bzr repo to act as "upstream" for this.  That might be a better
way for us to collaboratively add fixes.  Already added you to the group with
access to it.

Also add this check before anaconda runs in ltsp-build-client:

# python-ruledispatch conflicts with anaconda Bug #331091
if [ -d /usr/lib*/python*/site-packages/dispatch/ ]; then
   echo "ERROR: python-ruledispatch conflicts with anaconda.  Please remove it"
   echo "temporarily before running this script.  See Bug #331091."
   exit 1
fi

/etc/udev/rules.d/70-persistent-net.rules gets created by anaconda during chroot
installation, containing the host's interfaces.  This causes an ugly error
message during thin client bootup.  It should be deleted after anaconda is done.
 This this be done in ltsp-build-client (ltsp-server) or in the script in
ltsp-client?

(in reference to comment #58)

ltsp-client-configure (in ltsp-client) is where the current client-side changes
are being made. It would make sense to place this there.

For the ltsp root directory, consultation on fedora-devel and 
fedora-packaging list leads to /var/lib being prefered
(so /var/lib/ltsp5). That's also what I prefer. Any opposition?

/var/lib/ltsp5 would contain what?

We can bring this up during the LTSP hackfest this weekend.  Upstream will need
to accept any changes if we are to adopt them.

(In reply to comment #61)
> /var/lib/ltsp5 would contain what?

The client swap and the client roots. It corresponds with the
LTSP_DIR variable in /etc/ltsp5/ltsp.conf


> We can bring this up during the LTSP hackfest this weekend.  Upstream will need
> to accept any changes if we are to adopt them.

From my short exchange with Jim, he doesn't seem to care very
much.

Now that the init script for ltsp-dhcpd isn't started in the 
default case, and given that there is some code in dhcpd-update
to modify the config file for the main change, the ip of the server, 
I think that the hack to copy the file from /usr/share/ltsp5/config/ltsp-dhcpd.conf
should be removed, so ltsp-dhcpd.conf should directly be in 
/etc/ltsp5
and 02-ltsp-dhcpd-create should be removed.

I can do these changes in bzr if agreed. Also should the 
corresponding changes to the spec file be done in bzr?

I also have something similar than 06-xdm-config-update that
I would like to do, but for wdm. What do you prefer, a separate
file, or should I modify 06-xdm-config-update to be
06-xdm-wdm-config-update and arrange such that the configuration
of wdm is also done here? (wdm needs exactly the same change than 
xdm, the only difference is the location of the config file).

http://bzr.fedoraproject.org/hosted/k12ltsp/ltsp-server/HEAD/
Anonymous bzr
sftp://USERNAME.org/bzr/hosted/k12ltsp/ltsp-server/HEAD
Pull and push here if you work on the actual source.
https://hosted.fedoraproject.org/projects/k12ltsp/browser/ltsp-server/HEAD
Web Source Browser (doens't work with bzr)

Please hold off on changing anything in bzr until I'm done creating the basic
structure and write up some documentation.  I should finish this tomorrow morning.

Regarding ltsp-dhcpd.conf, I think it is a good idea.
I have no opinion on 06-xdm-config-update yet.

A ton of changes here, but thanks to bzr and diff of the noarch output of
ltsp-server-0 and this new version, I'm fairly certain it was all correct.

http://togami.com/~warren/fedora/ltsp-server.spec
http://togami.com/~warren/fedora/ltsp-server-4.99.1-1.fc8.src.rpm
* Wed Oct 31 2007 Warren Togami <wtogami> 4.99.1-1
- Require mknbi only on i386 and x86_64
- Add Etherboot to ltsp-dhcpd.conf template
- Use correct syntax for NFS mount
- Add anaconda chroot selinux warning
  We need to port the workaround from mock
- Minor fixes to ltsp-initialize (Patrice Dumas)
- Minor fix to 02-ltsp-dhcpd-create (Patrice Dumas)
- 06-xdm-config-update /etc/X11/xdm/xdm-config instead of /etc/X11/xdm/Xaccess
- 02-ltsp-dhcpd-create correct path to ltsp-dhcpd.conf
- Add anaconda python-ruledispatch conflict warning
- Move ltsp-dhcpd.conf back into /etc/ltsp5/
  remove 02-ltsp-dhcpd-create
- "make install" from Makefile
- remove some redundant requires
- preserve timestamp on pxelinux.0
- many spec cleanups

bzr branch http://bzr.fedoraproject.org/hosted/k12ltsp/ltsp-server/HEAD/
Please see how this is structured in bzr, and see README-DEVELOPMENT.  Next I
intend on adding "make srpm" and "make local" to the base Makefile to allow
quicker .src.rpm and local test builds.

Patrice, go ahead and add additional fixes.

Help Needed:
============
make tag
The bzr check before tagging is broken.  I fought for hours trying to get that
to behave properly.  Any ideas?

ltspfs-insecure has no reason to be implemented as a service.
It should simply be a configuration script -- called by 
ltsp-initialize either

1. directly
2. through a wrapper in /usr/share/ltsp5/scripts.d/ that would 
   just call the script.

I can implement 1. or 2. (in bzr), as you prefer, or let you 
fix that.


I don't think that vnc-ltsp-config should be required. It is
independent. Same for vino vnc vnc-server. I am not sure that
xorg-x11-server-Xorg is needed either.

I think the reason it is implemented as a service is because it loses setuid
every time the fuse package is upgraded.  Ultimately, this sucks and we need a
cleaner way to do this.

Can't PolicyKit help us here?  PolicyKit is already used to dynamically grant
access to devices like the optical drive to a logged in user.

One possible problem with relying on PolicyKit might be xattr limits on /dev
nodes.  Any idea how many simultaneous users can be added to fsacl's to a tmpfs
file?

I somewhat agree with removing those dependencies... although there is some
attractiveness of installing one package that pulls in everything people
typically use.  Perhaps we could instead rely upon a yum group and comps.

Another cleaner (but still ugly) method would be to use rpm triggers.  Whenever
package fuse is upgraded, run some-script that looks at /etc/sysconfig/something
before deciding to setuid the binary.  /etc/sysconfig/something is set by one of
the /usr/share/ltsp5/scripts.d/.

This gets rid of the service, but replaces it with a hidden trigger.  What is
more evil?

Let's look into how difficult it would be to get PolicyKit to do what we need first.

danpb explained a little about PolicyKit.  PolicyKit itself doesn't add the
fsacl's to /dev nodes.  A service (in this case HAL) asks PolicyKit if a certain
action is good, and the service itself takes care of it.  Need to look into how
hal works.

(In reply to comment #67)
> I think the reason it is implemented as a service is because it loses setuid
> every time the fuse package is upgraded.  Ultimately, this sucks and we need a
> cleaner way to do this.

I can't see why the fact that it should be run upon some event 
means that this should be a service. On linux, we try not to
solve the problems by rebooting ;-). In any case is having the
fuse mounts insecure a requirement for ltsp? It doesn't seems so
to me. 

> I somewhat agree with removing those dependencies... although there is some
> attractiveness of installing one package that pulls in everything people
> typically use.  Perhaps we could instead rely upon a yum group and comps.

This shouldn't be the main ltsp-server in any case. A meta-package could
be done, but it has to be separate (even if it is defined in the
ltsp-server spec).


It would be nice to have, for each script in /usr/share/ltsp5/scripts.d
a comment at the beginning explaining what the script does. For 
example it is not clear to me what does: 
07-xinetd-sysconfig-update


I have spotted an error in 10-runlevel-hack:
/usr/X11R6/bin/X
should be 
/usr/bin/X

In 15-kwin-update, it looks like to me that /usr/share/config/kwinrc
is now /usr/share/kde-settings/kde-profile/default/share/config/kwinrc

in 14-kdmrc-update the comment seems to be wrong. Also the code
        # add ICEwm to the session list
        if ($_ =~ /^SessionTypes=/i && $_ !~ /icewm/ ) {
                s/$/,icewm/;
        }

seems to be obsolete.


I also think that the performance tuning shouldn't be done in
the default case, that is 15-kwin-update shouldn't be run, and 
in 14-kdmrc-update the following shouldn't be done in the default
case:
        # turn off the clock
        if ($_ =~ /^LogoArea=Clock/ ) {
                $_ =  "#" . $_  ;
        }

If a fix looks absolutely correct, just go ahead and commit the change to bzr
with detailed comments in the commit and here.

OK, I am in agreement regarding requirements and meta-package.  Let's rip out
the unnecessary reqs for now.

> I can't see why the fact that it should be run upon some event 
> means that this should be a service. On linux, we try not to
> solve the problems by rebooting ;-).

Normally I would agree with you, but you have to think about the target audience
here... it is essential that we make things Just Work by default.  If this is
the case then a service is insufficient, RPM trigger would be the only option
until we figure out hal and PolicyKit, as it would fix itself immediately.

> In any case is having the fuse mounts insecure a requirement for ltsp? 
> It doesn't seems so to me. 

ltspfs (we don't have packages yet) relies upon fuse to mount USB keys, floppies
and optical media from the thin client.

(In reply to comment #71)

> Normally I would agree with you, but you have to think about the target audience
> here... it is essential that we make things Just Work by default.  If this is
> the case then a service is insufficient, RPM trigger would be the only option
> until we figure out hal and PolicyKit, as it would fix itself immediately.

I agree with the rpm trigger conditionalized on a sysconfig variable
as you said. But not with the service. The service is run on reboot, 
and it is not helpful in that case. So it seems to me that it should 
be a simple script run by a rpm trigger.

And it would also certainly be helpful to split it in 2, the modification
of /etc/udev/rules.d/99-fuse.rules should better be in ltsp5/script.d/xx-*, 
while the setuid change would be in the aforementioned script.
loading the fuse is already done in the fuse package.

> > In any case is having the fuse mounts insecure a requirement for ltsp? 
> > It doesn't seems so to me. 
> 
> ltspfs (we don't have packages yet) relies upon fuse to mount USB keys, floppies
> and optical media from the thin client.

So I think that it should be in that package, not here.

I am trying to fix the runlevel-hack script, but it is not clear to
me what should be done for gdm. The documentation and comments
in the custom.conf files are not clear at all.

My guess is to add, in custom.conf the [servers] section
0=Terminal

Is it right?

Created attachment 247101 [details]
bzr diff bring 10-runlevel-hack and 14-kdmrc-update uptodate

I didn't understood exactly what I should do to the
changelog. In any case it could look like
- bring 10-runlevel-hack and 14-kdmrc-update uptodate
  with kdm and gdm current setups

Did you bzr push after you made your local checkin?  I don't see any of your
changes in the repo.  We'll be working mostly offline during the hackfest so
more changes to the repo are coming.  We will occasionally go online to sync.

pushed now. I still haven't modified any changelog.

I committed your changelog entry for you.  Note that I did not bump the Version
or Release and did not include a version number in the changelog entry, because
we are not making a versioned tarball on this change alone.  We bump and include
V-R in changelog when we make a versioned tarball, probably after we add more fixes.

*** Bug 331531 has been marked as a duplicate of this bug. ***

This package is being thrown out, a new package is being made based upon
upstream.  Keeping this on the tracker only because it contains many notes that
might be useful.