Re: kFreeBSD future
Hi!
On 13/10/14 19:04, Andrew McGlashan wrote:
> So, is there currently ANY concern that kFreeBSD won't continue for
> Jessie and/or beyond Jessie? Are there enough people involved now to
> remove the risk for new users coming on board to use kFreeBSD, [...]
I'm hoping it doesn't come to that. As explained in
https://lists.debian.org/debian-bsd/2014/09/msg00282.html
by the time of the release team announcement, we'd already fixed d-i and
the RC bugs mentioned during the meeting. Only one RC bug, #740509
really concerns me now (affecting kfreebsd-i386 only).
Several developers were active on the port last month; there seems to
be more user interest since that announcement and I've noticed new
people contribute here and there.
If kfreebsd-* arches were dropped, we could still put out an unofficial
release with what we already have, and support the kernel for the
lifetime of jessie.
But what we'd probably lose are package mirrors for stable, and the
infrastructure to build security updates or stable-proposed-updates for
the whole package archive in a timely manner; these are critical for
production use.
If dropped from testing migration, packages might stop fixing bugs that
affect us, and over time large sets of packages could become out-of-date
and unable to build any more; that would leave testing/sid in a poor state.
> those needing an exit strategy from systemd on the main Debian release?
(include myself in that ;)
> Also, if people move systems to kFreeBSD and kFreeBSD stops being
> properly maintained and supported, is there a good migration path to
> FreeBSD or would it be a case of learning the whole FreeBSD system
> /ways/ over the Debian /ways/ ? How about ZFS, would the data on ZFS
> volumes be easily migrated, without rebuilding ZFS setups from scratch
> if the need arose?
We try to stay compatible with upstream's kernels, and allow for
GNU/kFreeBSD chroots on FreeBSD and vice-versa. ZFS volumes should be
portable between these systems.
(These are probably good questions to add to the Wiki FAQ...)
> What is the status of virtualization? I would like to replace xen which
> I am currently using with squeeze-lts -- is xen going to work with
> kFreeBSD? Is bhyve going to be a realistic option to use on kFreeBSD?
We haven't packaged any bhyve tools yet. In FreeBSD 10.x it still only
supports Intel CPUs and I don't have any of those to try it on.
GNU/kFreeBSD works fine as a Xen (HVM) domU since wheezy, and even
better in jessie because faster PV-HVM drivers are compiled in by
default. It can't be the Xen dom0 however; the host may have to be
Debian GNU/Linux or NetBSD.
Debian GNU/Linux wheezy is a really good Xen dom0 (much easier than
configuring it on NetBSD). This has the advantage that you could create
a LUKS LVM to store your virtual machines in, as an alternative to
setting that up inside the VM. You could have a minimal, unencrypted
dom0 that boots and starts up networking without password, then SSH in
to unlock and start wholly-encrypted VMs? Just remember to also encrypt
wherever VMs' memory gets suspended to on disk during a host reboot (I'm
guessing somewhere like /var/lib/xen/...?), and the host's swapspace (if
any).
> I am also interested in using FDE (full disk encryption), including /
> file system and use of dropbear ssh for mount time entry of LUKS pass
> phrases as I do with some current wheezy servers. Is there well
> documented ways to get systems up with these requirements?
As above; otherwise I think "full-disk encryption" is an odd expression
since there must be at the very least an unencrypted bootloader, and
typically the kernal and ramdisk too.
If you wanted to configure encryption within GNU/kFreeBSD instead... we
don't have an initramfs and thus don't have a dropbear-like mechanism to
unlock GELI-encrypted disks. Creative solutions to this are possible;
a minimal root filesystem could start up networking+ssh in runlevel "S"
then stop and wait; you could log in to unlock GELI disks, mount an
entire ZFS pool over the top of /, and resume boot.
Seems much easier though, if this is a VM, to let the host handle disk
encryption instead. You implicitly trust it anyway with your data and
encryption keys in RAM.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: