Inconsistent server IP: 192.168.0.[1-or-254]

this is not easy to change and initially these values were at such defaults on purpose because clients should not have access to any other networks, but we wanted to document the existance of the values ...
for now proper documentation should be done, if you change it in the package for users that have touched their dhcpd.conf before that will cause debconf prompts on upgrades for each and every user, we have the same problem here as in Bug 203954 for which we still have no proper solution that doesnt break existing setups.

ogra, thanks for the info.

Which of the two files should the users change in the mean time, to maximize their chances for non-breaking upgrades?
dhcpd.conf or /etc/network/interfaces?

I.e. is it preferable if they use 192.168.0.254 or 192.168.0.1?

well, hard to say :)

192.168.0.1 is often used for gateway adresses
192.168.0.254 is a not as usual address ...
the least intrusive would indeed be to change /etc/network/interfaces but that would cause trouble if we used it by default and a default gw in that network exists and uses this address ...

for documentation i would always go with changing /e/n/i if possible since this is not a conffile so it will never cause trouble on upgrades while dhcpd.conf will

> for documentation i would always go with changing /e/n/i if possible since this is not a conffile so it will never cause trouble on upgrades while dhcpd.conf will

I was worried about what would happen in the following scenario:
 * The user changes his IP to 192.168.0.1 from /etc/network/interfaces.
 * Karmic changes dhcpd.conf to use 192.168.0.254 instead of 192.168.0.1.
 * Debconf silently upgrades the user's dhcpd.conf, since he hasn't modified it.

In this scenario, his setup would brake on upgrade.

Thanks a lot! :-)

I'm going with 192.168.0.1 by default everywhere. This won't cause any change to existing config files, just to new installs so it seems safe and will fix the current mess.

I agree in the past not being able to access the network made sense, but now with localapps and fat clients, we definitely need a working network.

The user will still need to turn on forwarding and masquerading to give the thin clients internet access though but that's fine at least for now.

This bug was fixed in the package ltsp - 5.3.2-0ubuntu1

---------------
ltsp (5.3.2-0ubuntu1) precise; urgency=low

  [ Stéphane Graber ]
  * New upstream release (5.3.1)
    - A lot of Debian specific fixes (code path not used by Ubuntu)
    - Ensure /sys and /proc are always mounted when calling init-ltsp
    - Issue a message when ltsp-update-image is disabled
    - Ensure that lts.conf ends up in /etc
    - Only overwrite lts.conf if it has non-zero size
    - Only download tftp from $NBD_ROOT_HOST if it is defined
    - ltsp_config: delete the cache files on boot
    - Start ltsp-client-core only when an LTSP boot was requested
    - set_lts_var: remove old values from the cache file
    - Don't hardcode squashfs as the FSTYPE (LP: #696435)
    - ltsp-build-client: copy /etc/default/keyboard if it exists
  * New upstream release (5.3.2)
    - Use 192.168.0.1 consistently (instead of sometimes having .254)
    - Append to ltsp_config, don't overwrite it.
    - Rearrange init-ltsp.d scripts to set SERVER in more cases.
    - Remove I10-sound as it seems very deprecated.
    - Set sound volume on fat clients too (LP: #923923)
    - Disconnect NBD mounts when the ltsp-client service is stopped
    - Update xfreerdp script to handle the case where rdesktop or
      xfreerdp aren't there.
  * Replace dhcp3-server by isc-dhcp-server (package was renamed)
    (LP: #934014)
  * Setup a clean /etc/nbd-server/config if not already present
  * Use 192.168.0.1 everywhere by default. (LP: #390155)
  * Improvements to debian/ltsp-client-builder.postinst:
    - Wait for ltsp-update-image to actually exit. (LP: #813837)
    - Fix outdated check for universe (was looking for karmic ...)

  [ Alkis Georgopoulos ]
  * Drop mythbuntu debian/extra-plugins hook as it's now covered by the
    upstream fat client implementation and didn't work anyway.
  * Drop debian/ltsp-client-core.dirs as these are now created at boot
    time in ltsp-init.
  * Simplify debian/ltsp-client-core.install
  * LTSP 5.3 allows for ltsp-client-core to be installed on a regular
    machine, so there's no reason to prevent its installation.
    Drop ltsp-client-core.preinst and ltsp-client-core.templates and
    refresh the translations.
  * Drop nbdswapd from ltsp-server.postinst as that's now done in a
    named NBD export since LTSP 5.3.
 -- Stephane Graber <email address hidden> Thu, 23 Feb 2012 14:21:57 -0500