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 ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d02a9.4070...@pyro.eu.org