[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Diskless CDDs: ltsp and lessdisks

(so... at risk of cross-posting insanity, i have posted this to the
ltsp-developer list as it's purely LTSP related changes, and only
tangentially related to CDDs- perhaps futher discussion of this specific
thread should go there:

> > http://llama.freegeek.org/~vagrant/baz-archive/vagrant@freegeek.org--2005/
> > 
> > you should have considerably better luck, i hope. :)
> Much better.  I've started reviewing your patches; thanks for separating
> them out.
> patch-1	drop direct modification of /etc/exports in postinst/postrm to comply with debian policy
> 	You seem to imply that modifying /etc/exports is a policy violation.
> 	Did you assume it was a conffile? (it isn't)

upon looking into it, in debian sarge, nfs-kernel-server has
/etc/exports listed as a conffile.

but my impression is that editing of other packages configuration files
is also not allowed, though i couldn't really find this in debian-policy
explicitly.  in, section 10.7.4, it seems like you need to use a
provided tool to configure another package's configuration files(such as

in general, it doesn't seem like good practice for one package to modify
the configuration of another without administrator intervention... even
though it's really tempting to do. maybe i'm wrong.

> patch-2	support for tmpfs+bind mount alternative to unionfs
> patch-3	Improved descriptions
> patch-4	Corrected log message for patch-3
> patch-5	allow ssh as alternative to openssh-server and openssh-client for sarge compatibility
> patch-8	Copyright file changes
> patch-9	Explicit python dependency
> patch-10	support initrd-netboot-tools as alternative to initramfs-tools
> patch-12	TODO.Debian
> patch-13	sdm support
> 	Merged into mainline


> patch-6	Use atftpd in preference to tftpd-hpa
> 	Why is atftpd preferable?

i believe it is debconf pre-seedable, which is useful to CDDs. both
tftpd-hpa and atftpd work with PXE, i believe.
> patch-7	only set "LTSPROOT" and "clients" variables if not already set, pass these variables to ltsp-update-* from ltsp-build-client
> 	The hardcoded values do need to go away, but this isn't how I intended
> 	for it to work.  ltsp-update-kernels and ltsp-update-sshkeys always
> 	need to scan all client trees on the system, i.e. all of /opt/ltsp.

well, i needed them to work with the root dir configureable, and that
was the smallest change i could get for that to work.  if you go with
the defaults for ltsp-build-client (/opt/ltsp/ARCH), i believe the
behavior is unchanged(ltsp-update-kernels gets passed /opt/ltsp,
although ltsp-update-sshkeys will inherrit the appropriate architecture
/opt/ltsp/ARCH instead of hard-coded /opt/ltsp/i386).

> patch-11	/etc/default/ltsp-client-setup
> 	I merged this, then made changes to it:
> 	- Use debhelper to install the /etc/default file

much better to use debhelper, yes :)

> 	- Use an FHS-compliant directory (/var/run/ltsp)
using /var/run/ltsp won't work unless you move ltsp-client-setup to
later in the boot process, as /var/run gets cleaned shortly afterward
(S35mountall.sh, on debian sarge).

> patch-14	apt-get dist-upgrade in ltsp-build-client
> 	I don't understand why you did this; please explain

probably shouldn't have made the commit at that point- later in the
patches an extra mirror is added, which could possibly be security
updates or other package updates.  it would probably be good to allow
several additional mirrors.  lessdisks currently allows 5, though clever
ways to allow an arbitrary number would be even better.

> patch-15	Parameterization of ltsp-build-client
> 	Please don't change the defaults at the same time that you make
> 	other changes; it makes it more difficult for me to merge

with hindsight, i see that i should have made smaller changes with that

i should have simply started with the test -z "$FOO" && FOO=bar, and
made add-on defaults for sarge and etch, rather than putting the breezy
defaults into a case statement.

i was reverse-patching code that i had worked on for several days, so it
was a little tricky to get all the patches the way i would if i had been
properly using baz during development.

so, where do we go from here, since...

> patch-16
> patch-17
> patch-18
> 	Conflicted, presumably require patch-15

many of the patches are dependent on patch-15. though there are a few
later ones that probably don't require it.

of all the things needed in my opinion, dropping hard-coded values from
ltsp-build-client configuration is the most important thing, and
patch-16 introduces commandline options, which would be really nice.

i'm already up to patch 40... though everything after 25 is considerably
smaller patches, with hopefully less cruft.

trying to merge your changes back in, i get plenty of conflicts in
debian/changelog...  i suppose i should probably maintain a separate
branch for parts i don't expect to be shared.

though the biggest problem is that i've got two identical ids or
something, and 'baz status' chokes on this... ugh. seems like petter
also encoutered this problem, with more details posted :)

live well,

Attachment: signature.asc
Description: Digital signature

Reply to: