[Bug 593227] [NEW] feature request: add a root-path parameter
Alkis Georgopoulos
alkisg at gmail.com
Tue Jun 15 09:59:22 UTC 2010
Στις 15-06-2010, ημέρα Τρι, και ώρα 08:12 +0000, ο/η Oliver Grawert
έγραψε:
> just add an info function to the client and query it from the script :)
> (ldminfo in reverse ...)
Hi Oli,
if nbd-client was to be modified independently from nbd-server, we could
just make it send any info we want, and have our nbdrootd daemon read it
from stdin (inetd) before chaining to nbd-server. There's no need for
scripts and callback functions.
But I'd really prefer a clean upstream solution if it's possible, rather
than maintaining an nbd-client fork just for LTSP.
Btw speaking about LTSP differences, the nbd initramfs script uses
commas to separate the host from the port (nbdroot=*,*,*), while the
ltsp_nbd initramfs script uses colons (nbdroot=*:*) - wouldn't it be
better if the same conventions were used in both cases?
--
feature request: add a root-path parameter
https://bugs.launchpad.net/bugs/593227
You received this bug notification because you are a member of Edubuntu
Bugsquad, which is subscribed to ltsp in ubuntu.
Status in “ltsp” package in Ubuntu: New
Status in “nbd” package in Ubuntu: New
Bug description:
Currently nbd-server and nbd-client communicate using a different port for each image. So if e.g. an LTSP admin wants to use a chroot for nvidia-based clients and a chroot for the rest of his clients, he'd need to use two ports. And he wanted nbd swapping a third port would be needed.
This is inconvenient and makes IANA applications to standarize the nbd port impossible.
It'd be better if nbd-client supported two additional parameters, to be sent and processed by nbd-server at the negotiation stage:
* A -path=/path/to/desired/root option (which of course the server could ignore, if it wasn't in a pool of allowed paths), and
* A -swap=<requested size> option (to replace the current -swap option). If the server configuration allowed it, nbd-server (or some callback scripts) would create an appropriate swap flie of that size for the client.
More information about the edubuntu-devel
mailing list