From tek at serverop.de Tue Aug 4 22:43:15 2009 From: tek at serverop.de (Thomas Penteker) Date: Wed, 5 Aug 2009 00:43:15 +0200 Subject: [crux-devel] CRUX 2.6 Testiso with dm-crypt support Message-ID: <20090804224315.GA2020@serverop.de> Hello together, just like before the CRUX 2.5 release I packed together a test iso with support for an ecrypted root partition (on setup-time). I'd really like to get your feedback on this. Technically speaking there were not much changes that had to be done to the ISO repository, the diff [1] is really tiny. A new package named cryptsetup-initrd got added and its name makes its purpose quite obvious: it will enable you to build the required initial ram disk that allows the system to decrypt / during startup. I put the raw package [2] up for review, too. The test ISO [3] can be downloaded, too though I will upload a slightly fixed version tomorrow adressing a special use case mentioned in the /init script. To make your live easier I provide some documentation [4] covering the new parts for installation. The passphrase you have to provide your partition(s) could be provided via a USB-stick, too. This scenario is not yet covered by my documentation but I will add this, as soon as possible. Please let me know if you can think of any other ``authentication-scenario" that you would like to have added. There's only one issue left that may require discussion: when the boot process leaves initrd (switch_root /newroot) the real root's /dev directory is already mounted as tmpfs + populated but /sbin/start_udev calls ,---- [ head -2 /sbin/start_udev ] | # mount /dev as a tmpfs; note: some video drivers require exec access in /dev | /bin/mount -n -t tmpfs udev /dev -o exec,nosuid,mode=0755 | `---- so we end up with an (almost) empty /dev-directory. My idead was to check for the existence of /etc/.dev_populated (which would be creatd by our initrd before switch_root). If the file is available, start_udev should not (re)mount /dev but delete /etc/.dev_populated and continue execution after line #3. Currently this is not implemented so you'll have to comment out the command in /sbin/start_udev. Comments/Suggestions/critique is welcome! [1] https://serverop.de/~tek/crux-dmcrypt/ISO.DIFF [2] https://serverop.de/~tek/crux-dmcrypt/cryptsetup-initrd/ [3] https://serverop.de/~tek/crux-dmcrypt/crux-2.6-test0a.iso https://serverop.de/~tek/crux-dmcrypt/crux-2.6-test0a.iso.md5 [4] https://serverop.de/~tek/crux-dmcrypt/DM-CRYPT-STEPS kind regards, Thomas Penteker -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jue at jue.li Wed Aug 5 08:52:56 2009 From: jue at jue.li (Juergen Daubert) Date: Wed, 5 Aug 2009 10:52:56 +0200 Subject: [crux-devel] CRUX 2.6 Testiso with dm-crypt support In-Reply-To: <20090804224315.GA2020@serverop.de> References: <20090804224315.GA2020@serverop.de> Message-ID: <20090805085256.GA2713@jue.netz> On Wed, Aug 05, 2009 at 12:43:15AM +0200, Thomas Penteker wrote: > > Hello together, Hello Thomas, > just like before the CRUX 2.5 release I packed together a test iso with > support for an ecrypted root partition (on setup-time). > > I'd really like to get your feedback on this. First thanks for you work, but again you are very late with it, because we released an official 2.6-test1 already. Adding new features after that is something we should avoid. > Technically speaking there were not much changes that had to be done to the > ISO repository, the diff [1] is really tiny. Cryptsetup and dependencies should be added to packages.opt if we need them as packages on the ISO. Adding opt/popt to the ISO might create hidden problems, because other (core)ports will link against popt if installed. Currently our ISO bootstrap process can not prevent that, so we have to carefully check all packages after the bootstrap. > A new package named cryptsetup-initrd got added and its name makes its purpose > quite obvious: it will enable you to build the required initial ram disk that > allows the system to decrypt / during startup. > I put the raw package [2] up for review, too. I guess your final idea is to have a versioned tarball somewhere for download and not to provide the two binaries within the port? Do we really need a binary port at all? It should be possible to create cryptsetup-static in opt/cryptsetup? Is the busybox binary in any kind special for cryptsetup or can we use a new busybox port for that purpose? TBH I'm not convinced yet. I'd like to see a more general way/recipe for CRUX to switch to an initrd based startup as an alternative. This might be necessary for other things as well, e.g. I've heard that the kernel md-autodetect feature will be removed sometimes so you have to configure your raid with mdadmin at boot-time. best regards Juergen -- Juergen Daubert | mailto:jue at jue.li Korb, Germany | http://jue.li/crux From tek at serverop.de Wed Aug 5 22:05:41 2009 From: tek at serverop.de (Thomas Penteker) Date: Thu, 6 Aug 2009 00:05:41 +0200 Subject: [crux-devel] CRUX 2.6 Testiso with dm-crypt support In-Reply-To: <20090805085256.GA2713@jue.netz> References: <20090804224315.GA2020@serverop.de> <20090805085256.GA2713@jue.netz> Message-ID: <20090805220541.GA3410@serverop.de> * Juergen Daubert (jue at jue.li) wrote: > On Wed, Aug 05, 2009 at 12:43:15AM +0200, Thomas Penteker wrote: > (...) > First thanks for you work, but again you are very late with it, > because we released an official 2.6-test1 already. Adding new > features after that is something we should avoid. You are right, of course. My current working situation did not permit me to get this done earlier. > Cryptsetup and dependencies should be added to packages.opt if we > need them as packages on the ISO. > Adding opt/popt to the ISO might create hidden problems, because > other (core)ports will link against popt if installed. Currently > our ISO bootstrap process can not prevent that, so we have to > carefully check all packages after the bootstrap. That's true. Let me know if I can help out. > I guess your final idea is to have a versioned tarball somewhere for > download and not to provide the two binaries within the port? It'd save the user from going through (some) hassle, see below. > Do we really need a binary port at all? It should be possible to > create cryptsetup-static in opt/cryptsetup? Is the busybox binary > in any kind special for cryptsetup or can we use a new busybox port > for that purpose? It's not that easy to build it statically linked; libdevmapper needs to be linked statically for this, too, that's why I provided cryptsetup as a binary. > TBH I'm not convinced yet. I'd like to see a more general way/recipe > for CRUX to switch to an initrd based startup as an alternative. > This might be necessary for other things as well, e.g. I've heard that > the kernel md-autodetect feature will be removed sometimes so you have > to configure your raid with mdadmin at boot-time. The initrd-generating process is straight forward. Coming up with a script to automate this should be quite easy, e.g.: gen-initrd mdadm cryptsetup would include the mdadmin binary (with the needed calls to it taken from /etc/initrd/mdadm.conf or similar) + the cryptsetup binary with the necessary calls. The details for the different modules could be included a) in the script b) in a directory /etc/ge-initrd/$MODULE possibility a) is not as flexible as b) but easier to implement. But I do see a certain complexity in b) because one would have to include some information about the order in which the commands would have to be executed (just like udev does). ps: what about the suggested check for /etc/.dev_populated in /sbin/start_udev? kind regards, Thomas Penteker -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jue at jue.li Thu Aug 6 18:27:16 2009 From: jue at jue.li (Juergen Daubert) Date: Thu, 6 Aug 2009 20:27:16 +0200 Subject: [crux-devel] CRUX 2.6 Testiso with dm-crypt support In-Reply-To: <20090805220541.GA3410@serverop.de> References: <20090804224315.GA2020@serverop.de> <20090805085256.GA2713@jue.netz> <20090805220541.GA3410@serverop.de> Message-ID: <20090806182716.GA21574@jue.netz> On Thu, Aug 06, 2009 at 12:05:41AM +0200, Thomas Penteker wrote: > * Juergen Daubert (jue at jue.li) wrote: > > On Wed, Aug 05, 2009 at 12:43:15AM +0200, Thomas Penteker wrote: > > (...) > > First thanks for you work, but again you are very late with it, > > because we released an official 2.6-test1 already. Adding new > > features after that is something we should avoid. > > You are right, of course. My current working situation did not permit me to > get this done earlier. > > > Cryptsetup and dependencies should be added to packages.opt if we > > need them as packages on the ISO. > > Adding opt/popt to the ISO might create hidden problems, because > > other (core)ports will link against popt if installed. Currently > > our ISO bootstrap process can not prevent that, so we have to > > carefully check all packages after the bootstrap. > > That's true. Let me know if I can help out. > > > I guess your final idea is to have a versioned tarball somewhere for > > download and not to provide the two binaries within the port? > > It'd save the user from going through (some) hassle, see below. Sorry, I mean a tarball with at least the two big binaries busybox and cryptsetup in it. With your current solution ever user is forced to download them with ports -u. > > > Do we really need a binary port at all? It should be possible to > > create cryptsetup-static in opt/cryptsetup? Is the busybox binary > > in any kind special for cryptsetup or can we use a new busybox port > > for that purpose? > > It's not that easy to build it statically linked; libdevmapper needs to be > linked statically for this, too, that's why I provided cryptsetup as a binary. > Not a problem, having a static libdevmapper seem to be a good idea anyway. I'll commit an updated version of libdevmapper soon. best regards Juergen -- Juergen Daubert | mailto:jue at jue.li Korb, Germany | http://jue.li/crux From jw at smts.ch Sun Aug 16 08:59:58 2009 From: jw at smts.ch (Johannes Winkelmann) Date: Sun, 16 Aug 2009 10:59:58 +0200 Subject: [crux-devel] Retirement Message-ID: <20090816085958.GA3925@selenium.smts.lan> Hi there, As most of you probably noticed I've spent very little time on CRUX in the past quarter, and it doesn't look like things will change anytime soon, therefore I've decided to resign from CRUX' development. It's been a great opportunity working with so many talented people, and I hope that at some point in time we can do a CRUX alumni gathering. Best wishes, Johannes -- Johannes Winkelmann mailto:jw at smts.ch Zurich, Switzerland http://jw.smts.ch From richard.poettler at gmail.com Tue Aug 25 14:37:18 2009 From: richard.poettler at gmail.com (=?UTF-8?Q?Richard_P=C3=B6ttler?=) Date: Tue, 25 Aug 2009 16:37:18 +0200 Subject: [crux-devel] Retirement Message-ID: <5f52f29b0908250737v777894d6j22c543734683c130@mail.gmail.com> Hi, you have noticed it for sure - I haven't been very active in the crux development since the last half year or so. I didn't have much time, and the little time I had available I didn't want to spend it hacking my computer... So i came to the conclusion, that it would be the best for me and the project, that I retire. I want to thank you for the great community! I've also learned a lot from you - thanks for that. bye richi (namenlos) From tilman at crux.nu Fri Aug 28 16:50:00 2009 From: tilman at crux.nu (Tilman Sauerbeck) Date: Fri, 28 Aug 2009 18:50:00 +0200 Subject: [crux-devel] pkgutils patches In-Reply-To: <8e04b5820907081233v5508f7f9u6083e85ed9b303d7@mail.gmail.com> References: <8e04b5820907081230x71aaf375t44367fc399ed1328@mail.gmail.com> <8e04b5820907081233v5508f7f9u6083e85ed9b303d7@mail.gmail.com> Message-ID: <20090828165000.GA1269@code-monkey.de> Ciprian Dorin, Craciun [2009-07-08 22:33]: Hi Ciprian, sorry for getting back to you so late. > ? ?I've made some (minor) modifications to pkgutils, which are > available from my Git repository (given below), so if you're > interested, please merge them in. (Even if not I would appreciate some > comments. :) ) > [...] Your patches sound fine and I'll try to have a closer look and possibly merge them soon. Thanks, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: