-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi,
First off, thank you very much Steven. On 14/10/2014 10:02 PM, Steven Chamberlain wrote: > 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). Yes, I read that and I assumed as much, but as I've let others know about the potential option to switch ti kFreeBSD ... well, I thought I better get some clarification. Hopefully we'll be okay. > 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. I'm afraid that if it gets dropped, then I may not get started with kFreeBSD ... in that case, I might go with FreeBSD direct, but I'll have quite a bit more learning to do. > 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. That sure wouldn't help. > 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. That's great. > (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. Do you mean amd64 or Intel specifically? > 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. That's good to know. I might be able to play around with kFreeBSD that way, although the problem for me is that I might not have enough RAM available to do that on currently available equipment at my disposal. > 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). Debian GNU/Linux wheezy might be the answer for Xen Dom0 then, at least for a while. >> 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. Not really, I've got a couple of Thecus N4800Eco units, they have 4x 4TB disks installed and also a SATA port with plenty of room for /boot partition on a 1GB sized SATA disk that looks a bit like a USB stick, but it isn't USB. I use dropbear to get an ssh environment where I can enter pass phrases for the encrypted root file system disk and I also do the same for other crypt volumes (all LUKS). That works really well. I can handle just /boot being without encryption. > 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. Yes, for sure. Thanks very much once again. Your post is very helpful and I greatly appreciate all the work you are doing with kFreeBSD. Cheers A. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iF0EAREIAAYFAlQ99tQACgkQqBZry7fv4vtiuAEAjM0ivuIQhobovKd9XP14pjMd bzkW+prvmDxjetIObeYA+NjhNc+zOqAw4QHLwjzXdh0q3xKh/IJijv3TX2B3h7U= =iOLt -----END PGP SIGNATURE----- -- 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/543df6d7.2040...@affinityvision.com.au
