Re: Dnsmasq instead of dhcp3/tftpd-hpa and other ideas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/17/2012 07:48 AM, Alkis Georgopoulos wrote:
> Hi all,
> =

> if noone objects, I'd like to commit quite a few changes upstream
> in the next few weeks. Some of those ideas are new; some have been
> mentioned in #ltsp several times in the past. I've tested most of
> them while developing an ltsp-server alternative called "ltsp-pnp"
>  (https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp), which I
> would also like to merge with upstream.
> =

> 1) Recommend: dnsmasq instead of isc-dhcp-server/tftpd-hpa.
> Benefits:
> =

> * Dnsmasq can be used as a proxy DHCP server =

> (https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP), and that =

> will make ltsp-server installation much easier in single-NIC cases =

> where an external DHCP server is used (e.g. a router, very common =

> setup in small labs, schools etc). The dual-NIC case is very easy =

> too, dnsmasq can function as a normal DHCP server in the internal =

> 192.168.67.x subnet. I'm proposing 192.168.67.x instead of the
> usual 192.168.0.x, because the latter is commonly used for the =

> external-facing NIC, causing conflicts. * Dnsmasq supports a
> dnsmasq.d/ directory where we can drop our configuration files, a
> static one =

> (http://bazaar.launchpad.net/~alkisg/+junk/ltsp-pnp/view/head:/etc/dnsmas=
q.d/boot-server.conf)
>
> =

and a small dynamic dhcp-ranges.conf, automatically generated on
> postinst and updated whenever the user moves the server to a new =

> subnet and runs /usr/share/ltsp/update-dhcp-ranges =

> (http://bazaar.launchpad.net/~alkisg/+junk/ltsp-pnp/view/head:/ltsp-pnp/u=
pdate-dhcp-ranges).
>
> =

* Dnsmasq can function as a caching DNS server too, which is very
> nice to have for localapps and fat clients. I propose we enable it =

> by default, and if someone doesn't want it, he can disable it. *
> Dnsmasq can function as a TFTP server as well. It even supports =

> symlinks from the TFTP dir to other dirs by default, and that will =

> come in very handy for NFS chroots, where we can symlink =

> TFTP/ltsp/arch/ to CHROOT/boot. That change is a big one, and
> anyone that wants to revert to tftpd-hpa will need to remove the
> --secure option from its configuration. Symlinks are also handy for
> lts.conf, which we can now put in /etc/ltsp/lts.conf, and for
> syslinux (/usr/lib/syslinux), which we can use for graphical
> PXELinux menus.

- From past experience with dnsmasq in Ubuntu, there are a few things
that will need fixing before I consider changing the default:
 - dnsmasq's tftp server takes over 5 minutes to send kernel+initrd
when client is in kvm (might depend on bootrom/nic) where tftpd in the
exact same environment takes <1 second. Clearly a bug but clearly a
blocker as it prevents efficient QA and testing.
 - The Ubuntu Security team did an evaluation of dnsmasq's caching DNS
server and decided that it's currently not safe, allowing easy cache
poisoning and letting users see what others are doing. That's why even
though we use dnsmasq in Network Manager for 12.04, we disabled its
caching feature entirely. I don't think the security team will fight
against LTSP as much as they did against the Network Manager change,
but it's certainly something that'd need discussing.
 - Ubuntu needs to have an upgrade path from pre-dnsmasq to dnsmasq.
We don't support chroot upgrade (yet) but we do support server
upgrade, so if we end up doing the switch, we'll need to careful test
and design the upgrade process for it to work without breaking default
and slightly customized setups.


> 2) ltsp-update-kernels will get the kernels from within NBD files,
>  instead of CHROOTs, so that no kernel version mismatches happen.
> For NFS, it will generate the TFTP symlinks. If the same chroot is
> exported with both NBD and NFS, two TFTP dirs are necessary, due to
> possible kernel mismatches, so new names will need to be
> introduced, i.e. TFTP/ltsp/i386-nbd and TFTP/ltsp/i386-nfs. Code to
> be merged: =

> http://bazaar.launchpad.net/~alkisg/+junk/ltsp-pnp/view/head:/sbin/ltsp-u=
pdate-kernels

Sounds
> =

sane, haven't looked at the branch though.

> 3) ltsp-update-sshkeys and LDM will use hostnames instead of IP =

> addresses. This will make it possible to change the server IP
> without having to run ltsp-update-sshkeys and possibly
> ltsp-update-image, and without the need for ssh-hostchecker. If
> someone has more LDM_SERVERs, he'd need to put them in hosts.ltsp
> (we have support for that now already) and specify them by name in
> lts.conf.

What happens when you don't have an hostname/dns record associated
with your server (which I believe is still the majority of setups)?

> 4) Out the the box support for graphical PXE menus =

> (http://bazaar.launchpad.net/~alkisg/+junk/ltsp-pnp/view/head:/ltsp-pnp/u=
pdate-pxe-menu).
>  Called by ltsp-update-kernels, a script named =

> /usr/share/ltsp/update-pxe-menu will merge all TFTP/*/pxelinux.inc
> files to a master TFTP/pxelinux.cfg/default. The result will be
> something like: http://imagebin.org/index.php?mode=3Dimage&id=3D207317 =

> Dirs under TFTP/ltsp will be sorted in an ascending order, while
> kernels inside them in a descending order, and also options for
> memtest or localboot will be available by default, and the sysadmin
> can disable them if he doesn't want them.

Looks good but will need very careful testing, some of these menus
work pretty much everywhere (like gfxboot menu on the Ubuntu CD), some
fails on a wide range of hardware (grub boot menu). These issues
mostly appear on old hardware which in LTSP's case can be a problem.

> 5) An ltsp-export-root tool, which generates an NBD image out of
> the server /. It bind-mounts / to a temp dir, uses a tmpfs/aufs to
> be able to do changes over it before exporting, removes the user
> accounts, regenerates the server ssh keys or other sensitive data,
> and calls mksquashfs. The code to be merged exists in the prepare.d
> and publish.d dirs in =

> http://bazaar.launchpad.net/~alkisg/+junk/ltsp-pnp/files/head:/ltsp-pnp/.
> That's the essense of ltsp-pnp, i.e. allowing non-experienced
> sysadmins to manage LTSP without a chroot; they just install
> whatever they want in their server and export it. Of course
> services like apache, mysql etc are prohibited from running in the
> clients with the RM_SYSTEM_SERVICES lts.conf option.

Sounds good in principle but just looking at your description, it'll
fail miserably if you have split partitioning, for example if /usr is
on a separate partition.
Again, I haven't looked at the code, but I'm guessing you'll want to
use rbind instead of bind mounts and then one overlay filesystem per
mount points mounted on top of / except for some well known mount
points we don't want in there (proc, sys, tmpfs, ...).

> 6) Ship an /etc/ltsp dir by default, which will contain a sample =

> lts.conf, a vendor.conf with distro-specific variables
> (BASE=3D/opt/ltsp; DNSMASQ_DIR=3D/etc/dnsmasq.d; etc), an nbd-exclude
> file which specifies what to exclude from the generated NBD image,
> and some *.inc files for the PXE menus, where the sysadmin can
> localize the PXE text, customize the PXE menus and other options. =

> Also ship an /etc/default/ltsp file (non-debian distros use a
> different dir for defaults) where the sysadmin can specify the PXE
> menu default entry, whether to automatically update the dnsmasq
> dhcp ranges, additional kernel command line options, IPAPPEND=3D2/3
> etc.

Sounds good.

> Since there are a lot of changes, the trunk will be somewhat
> unstable for some weeks. We may also want to consider naming it
> LTSP 6, and when the libpam-sshauth and the possibility to use
> another DM instead of LDM are there, we can name that LTSP 7.

The above sounds more like LTSP 5.4 than LTSP 6 as it's mostly
internal changes. I still think we should wait for libpam/libnss-ssh
and the lightdm/whatever-dm switch before tagging LDM 3 and LTSP 6.

> Comments? If noone objects, I'll start committing after a few days,
>  otherwise I'll keep developing ltsp-pnp in a separate tree. =

> Thanks!

Quite a few comments above :)


- -- =

St=E9phane Graber
Ubuntu developer
http://www.ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPjUWqAAoJEMY4l01keS1nwP0QAM6QCtI9fuIUGuUs/sTGJ8tw
CUA8Pz/k+Gu+YLd7KUeNOU7egxHXIHTzdwoGz9dPUAJZgBXzuMP33ZOr8vpxLjGj
4tc5bSYkE3daA6ajTktP/HS5pHDVSSJGYEqWiuLVGga7TFSf+gmXvtkrXjUMe4Nz
7whhZeUbSsxUxSjFntKieKgWPLzvS/Qu/W9e3Qm10YqKcvgOCigG+A9YeMf7C0sp
tLPzTIC50h6DtIlhNqFCDuOUc2NNsrgnxHJKfKSIfeB768P6vVpVeyd9nF9kMTfB
kzJ66KmSW5/HueCO9WeYHO2lqeSqLO24Gfqv4jQSSP+6H6M0nmBYTOq/gUMmEzHs
zAOErNZR0kLV9rfajAkirSCxKb2ylSBaRcaIkx5/HUROnMK23+6SGwBsXnVECbb7
Cbi1/KSY9Gn4cM4w53JRbPop4cMLLfhhs5vTxdWNJfeCb1irv8eEHdfriWxrVODZ
PLeZFgCDPaviIHcArnoIwkDkEtRnMtDFxgBkM/G2PHKg0n5Od8Rc1GY/cCWlSV/Y
4ICbz5sdBLEhACMoi5ati717XVER/OP3R6O/d/4UOVdPA1GAVEXrRbM5FY7Qf1OI
HuJ4NagmPAKYW73cqH8NQ8raNNyQA3LdmheggiGbrLJviVKvv3uTpfMa7+3vg2Nm
xofWGULO9cqbyRLX2TOt
=3DcZ7A
-----END PGP SIGNATURE-----

---------------------------------------------------------------------------=
---
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second =

resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net