Re: LUKS-encrypted root and unencrypted /boot ?
Benjamin Slade writes: > I mused briefly about mirroring of the relevant things (kernels, initrd) > from /gnu/store to /boot, but that's probably pretty hack-y. The parts of GuixSD which require maintaining state outside of the store tend to be a little complicated (in my opinion) because they don't fit neatly into the "functional software deployment model" bubble that the rest of Guix lives in. We currently do this for the GRUB config: we copy it out of the store into the /boot directory, instead of symlinking it. I believe this was done in order to support the use case of putting /gnu/store and /boot on different partitions. Technically, I think we could do the same sort of thing for Linux kernel images and initrds, but what's the goal? If the goal is just to make it so GRUB doesn't have to open the LUKS volume in order to boot, then your solution already meets the goal. However, since your solution puts all of /gnu/store in an unencrypted partition, you should keep in mind that anything you put in the store will also be unencrypted. Therefore, if you add anything from your home directory to the store (e.g., by using local-file [see: (guix) G-Expressions]), it may be exposed in the store. That said, since the store is generally readable by everybody on the system (and remotely, if you are using "guix publish"), one probably shouldn't be putting sensitive information in the store to begin with. Hope that helps! -- Chris signature.asc Description: PGP signature
Re: How should I install non-guix software?
Hi Luther, Those are really good questions. I'll try to explain what I know, and hopefully it'll be useful to you. Luther Thompson writes: > I don't know if this has been discussed before, but is there a best > practice for installing software from outside the Guix package system? For custom packages, you can define your own via the GUIX_PACKAGE_PATH. See "Package Modules" in the Guix manual for how to do that [1]. For software installed via other package management tools like npm, Maven, or pip, it's trickier. Those package managers ought to work out of the box. I use Maven (installed via Guix) frequently on a GuixSD system, and it's always worked well for me. However, because (1) those package managers don't provide the same kind of strong guarantees about dependencies that Guix does, and (2) because GuixSD doesn't follow the FHS (for good reasons), there is definitely the risk that some software you install via those other package managers won't work correctly out of the box on GuixSD. > If I have a source tarball for a program that doesn't have a Guix > package, or if I write my own program, there just isn't any good place > to put the installed files. Scripts have the additional problem of not > being able to use their shebang line. Yes, the hard-coded references are a common problem. It's always been a problem when software assumes that the components they require will exist at certain absolute paths, since even among systems that don't use Guix these paths can vary. Software that has been designed from the start to be portable will sometimes mitigate this problem by providing a way for users to tell the program where its dependencies live (e.g., via an option to the ./configure script). However, this is still a common problem. I know of at least a few ways to deal with this problem. They are: 1) Work with upstream to provide a way for users to specify the location. For example, Pierre is doing this for magit right now [2]. 2) Replace every hard-coded occurrence of the path with a correct path. We do this all the time. For just one example, refer to the use of the substitute* procedure in the package definition for pies (run "guix edit pies"). 3) Run the software in an environment where its expectations are met. For (3), like you suggested, one way to do it is to create symlinks in your system. That's fine for a quick, local solution, but it isn't appropriate for software that will be included in Guix proper. I've sometimes created "/bin/bash" and "/usr/bin/env" on my system for reasons like this. When using GuixSD, you can define these kinds of files in your OS configuration using the special-files-service-type. See "Base Services" in the manual for details [3]. > As a more unique example, I was recently using a React tutorial. IIRC, > I ran the command `npm start`. It tried to run another installed script. > I had to manually change the shebang line of that other script to point > to /home/luther/.guix-profile/bin/node to get it to run. The build systems of Guix (e.g., gnu-build-system) generally have a build phase that automatically finds and patches shebang lines, replacing them with absolute paths to the corresponding interpreters in the store. Unfortunately, if other package managers like npm, Maven, pip, etc. do not provide a way to change hard-coded paths - and I don't think any of them do - this will always be a problem. In my opinion, if you have to use these kinds of tools to install software on GuixSD, the best compromise is probably to create symlinks in your system as above. As far as I know, there isn't a good, holistic way in GuixSD to deal with hard-coded paths in software that has been installed via other package managers like npm. If someone knows better, I'd love to hear otherwise! > 1. Write a Guix package for every little piece of software we want to > run. I have yet to successfully do this, but I might decide to learn > someday. I already know Scheme. AFAIK, this won't work for node > packages, but it should work for everything else. This solution would > be a lot of work for users. In some ways, this is the best approach. However, I know it's easier said than done. If you're ever feeling stuck, you can ask for help here as long as the software you're trying to package is free software. It's also helpful to look at the thousands of existing examples in the Guix source tree, which are located in the gnu/packages directory. > 2. Put ~/bin in our $PATH and install all our executables there. This > wouldn't work for the majority of software that installs more than just > executable files. I'm not sure what you mean here. How would putting ~/bin in your $PATH enable software that hard-codes a path of "/bin/bash" to find the bash program? > 3. Instead of installing the software, run it directly from whatever > directory we unpacked/compiled it to. Wouldn't this also fail to address the problem of hard-coded paths? > 1. Make a
How should I install non-guix software?
I don't know if this has been discussed before, but is there a best practice for installing software from outside the Guix package system? If I have a source tarball for a program that doesn't have a Guix package, or if I write my own program, there just isn't any good place to put the installed files. Scripts have the additional problem of not being able to use their shebang line. As a more unique example, I was recently using a React tutorial. IIRC, I ran the command `npm start`. It tried to run another installed script. I had to manually change the shebang line of that other script to point to /home/luther/.guix-profile/bin/node to get it to run. I can think of a few solutions, all of them difficult: 1. Write a Guix package for every little piece of software we want to run. I have yet to successfully do this, but I might decide to learn someday. I already know Scheme. AFAIK, this won't work for node packages, but it should work for everything else. This solution would be a lot of work for users. 2. Put ~/bin in our $PATH and install all our executables there. This wouldn't work for the majority of software that installs more than just executable files. 3. Instead of installing the software, run it directly from whatever directory we unpacked/compiled it to. Unless we use solution 1, we also need a solution for scripts. 1. Make a soft link at /usr/bin/env in the root filesystem pointing to /run/current-system/profile/bin/env. This seems like the simplest solution, but I figure there must be some reason the devs haven't already done this. 2. Know which interpreter we need for each program and invoke that interpreter explicitly. 3. Manually change the shebang line for every script to point into our .guix-profile. I don't like this idea, because it would mean hard-coding the name of our home directory into every script. We can't really do that with programs that we want to hack on and publish. Currently, I invoke binaries from their own directories and for scripts, I invoke the interpreters. I've only been using GuixSD for a short time, so I doubt that this is a fool-proof solution. How do you guys handle this? Luther
Re: mcron
Many thanks, Pierre. Can one also mix Vixie-style things in `~/.config/cron/` ? It probably doesn't matter since I think I've figured out mcron native syntax. I was looking everywhere in "(mcron) Top" for an example of "do X every N minutes", but finally figured out that this works (at least I hope so): --8<---cut here---start->8--- (job '(next-minute (range 0 60 5)) "dosomethingevery5minutes") (job '(next-minute (range 0 60 10)) "dosomethingevery10minutes") --8<---cut here---start->8--- -- Benjamin Slade - https://babbagefiles.xyz `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19)) '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org ) `(Choose Linux ,(Choose Freedom) . https://linux.com )
Re: mcron
No, mcron at the user-level is even simpler, simply tweak your configuration file and start `mcron`. Example job in ~/.config/cron/job.guile: --8<---cut here---start->8--- (job '(next-hour (range 0 24 3)) "updatedb") --8<---cut here---end--->8--- Once mcron is running, you can test the schedule by calling `mcron --schedule=5` to list the 5 next scheduled jobs. Have a look at "(mcron) Top", it's a very short read ;) -- Pierre Neidhardt signature.asc Description: PGP signature
Re: mcron
On 2018-08-04T02:44:24-0600, Pierre Neidhardt wrote: > Not sure I can help much here because I personally run help cron from my user > session, i.e. with "mcron &" in my ".profile". I declare the jobs in > "~/.config/cron/job.guile". > Maybe you could try that for the user-level jobs and see if it works in that > condition? Thanks, Pierre. What is the procedure for declaring jobs in `~/.config/cron/job.guile` ? For the `/etc/config.scm` method, as far as I understand it, the jobs need defining and then enabling/calling. Does it work for the same for the user session cron in `~/.config/cron/job.guile` ? thanks, ---Ben -- Benjamin Slade - https://babbagefiles.xyz `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19)) '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org ) `(Choose Linux ,(Choose Freedom) . https://linux.com )
Re: LUKS-encrypted root and unencrypted /boot ?
> > Thanks, I'll look into that. For the moment I've just switched to > > having an unencrypted root and encrypted /home partition (where the > > swapfile also lives), > > ...which seems to me better from a security standpoint (I can > > use --iter 500, sha512, without an issue). > But it's easier put a malware in an unencrypted root ;) That's true, but if someone has the time/access to be putting malware in the unencrypted root of an GuixSD install (will they know to put things in /gnu/store ?) they could also install physical keyloggers and so on (perhaps more efficiently). So while I'd prefer to have the whole thing encrypted, realistically I'm mainly protecting my personal data if it's stolen/taken from me (as long it's off, that is). -- Benjamin Slade - https://babbagefiles.xyz `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19)) '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org ) `(Choose Linux ,(Choose Freedom) . https://linux.com )
Re: Magit interactive rebase error: perl not found
OK, I figured it out, it's in the `magit--cherry-move' function: --8<---cut here---start->8--- (push (format "%s=perl -i -ne '/^pick (%s)/ or print'" "GIT_SEQUENCE_EDITOR" (mapconcat #'magit-rev-abbrev commits "|")) process-environment) --8<---cut here---end--->8--- This "perl" could not be automatically detected by the Guix path-patchers. We could patch this but I think this also deserves an upstream fix: https://github.com/magit/magit/issues/3537 -- Pierre Neidhardt signature.asc Description: PGP signature
Re: LUKS-encrypted root and unencrypted /boot ?
Benjamin Slade writes: > Thanks, Clément. You're welcome! > > > > Do you use Libreboot? > > > > > > Yes, I'm using Libreboot. Does this make a great difference over the > > > manufacturer firmware in this case? > > > It might, because the GRUB used is the one shipped with Libreboot. > > So it has nothing to do with Guix. I think talking to the libreboot > > people would help you more. (Disclaimer: I have the same issue, I > > find that pressing 'c' and typing 'cryptomount ahci0,gpt3' makes the > > process faster.) > > Thanks, I'll look into that. For the moment I've just switched to having > an unencrypted root and encrypted /home partition (where the swapfile > also lives), > ...which seems to me better from a security standpoint (I can > use --iter 500, sha512, without an issue). But it's easier put a malware in an unencrypted root ;)
Re: LUKS-encrypted root and unencrypted /boot ?
Thanks, Clément. > > > Do you use Libreboot? > > > > Yes, I'm using Libreboot. Does this make a great difference over the > > manufacturer firmware in this case? > It might, because the GRUB used is the one shipped with Libreboot. > So it has nothing to do with Guix. I think talking to the libreboot > people would help you more. (Disclaimer: I have the same issue, I > find that pressing 'c' and typing 'cryptomount ahci0,gpt3' makes the > process faster.) Thanks, I'll look into that. For the moment I've just switched to having an unencrypted root and encrypted /home partition (where the swapfile also lives), which seems to me better from a security standpoint (I can use --iter 500, sha512, without an issue). > > > I'm unsure [using an unencrypted /boot] would help, because GRUB > > > would still have to unencrypt / to access the kernel (the kernel > > > is in /gnu/store). > > > > Ah, I see. Is this an immutable design decision? It would seem > > good to be able to keep the kernel in a separate space in order to > > avoid the issue of extremely long unlocking times when booting. > Nothing is immutable, but it's a strong design decision that all > packages data are put in /gnu/store. Linux is just one of them. > Plus, a characteristic of GuixSD is that you can revert to previous > configurations. Those configurations appear as GRUB lines. Each > configuration could have a different kernel and kernels take space, > so it wouldn't scale well. Plus, I think some other stuff is needed > as well, like the initrd, which is large too, etc. I mused briefly about mirroring of the relevant things (kernels, initrd) from /gnu/store to /boot, but that's probably pretty hack-y. -- Benjamin Slade - https://babbagefiles.xyz `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19)) '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org ) `(Choose Linux ,(Choose Freedom) . https://linux.com )
Re: Upgrade errors, Re: Upgrade errors
> According to the example in the manual ("(guix) Using the Configuration
> System"), you should replace
>
> (file-system-label "root-fs")
>
> with
>
> "root-part"
Doing so (and doing 'guix system reconfigure /etc/config.scm') results
in the following error:
/etc/config.scm:29:22: error: device 'root-part' not found: No such
file or directory
However replacing "root-part" in your suggestion with
"/dev/mapper/root-part" (as suggested for mapped devices in File
Systems (sec. 6.2.3) of the manual) avoids above error. It seems that
the manual example config.scm with mapped-devices needs to be
corrected in the above manner.
But the pesky original issue of user-homes and term-auto services
could not be started remains even after specifying
"/dev/mapper/root-part". Does the error have something to do with my
using just a single (encrypted) partition for everything (including
/home)?
Regards
sidhu1f
On Sat, Aug 4, 2018 at 2:03 PM, Pierre Neidhardt wrote:
> I haven't tested but at first glance I would say that the target of the
> mapped-device and the root filesystem device don't match: one is "root-part"
> and
> the other is (file-system-label "root-fs").
>
> According to the example in the manual ("(guix) Using the Configuration
> System"), you should replace
>
> (file-system-label "root-fs")
>
> with
>
> "root-part"
>
> Also watch out with those `cons', you should use `cons*' or `list' if someday
> you'd like to add more than one element.
> --
> Pierre Neidhardt
Re: Atom text editor?
I had missed this great article, thanks for the link! -- Pierre Neidhardt signature.asc Description: PGP signature
Re: Atom text editor?
Il giorno sab 4 ago 2018 alle ore 11:00 Tim Smith ha scritto: > Is anyone working on adding the Atom text editor to Guix? It would be > great to have it available. > > https://atom.io/ > https://en.wikipedia.org/wiki/Atom_(text_editor) > > Tim > Atom is based on nodejs Currently nodes based projects cannot be ported in Guix The issue has been discussed on this mailing list (search "jquery" in the subject) and there is also this blog post http://dustycloud.org/blog/javascript-packaging-dystopia/
Atom text editor?
Is anyone working on adding the Atom text editor to Guix? It would be great to have it available. https://atom.io/ https://en.wikipedia.org/wiki/Atom_(text_editor) Tim
Re: mcron
Not sure I can help much here because I personally run help cron from my user session, i.e. with "mcron &" in my ".profile". I declare the jobs in "~/.config/cron/job.guile". Maybe you could try that for the user-level jobs and see if it works in that condition? -- Pierre Neidhardt signature.asc Description: PGP signature
Re: Upgrade errors, Re: Upgrade errors
I haven't tested but at first glance I would say that the target of the
mapped-device and the root filesystem device don't match: one is "root-part" and
the other is (file-system-label "root-fs").
According to the example in the manual ("(guix) Using the Configuration
System"), you should replace
(file-system-label "root-fs")
with
"root-part"
Also watch out with those `cons', you should use `cons*' or `list' if someday
you'd like to add more than one element.
--
Pierre Neidhardt
signature.asc
Description: PGP signature
Re: Upgrade errors, Re: Upgrade errors
Hi Chris Apologies for the delay in response. Meanwhile I have done a clean reinstall of guix version 0.15 and the error persists: ... shepherd: Service user-homes could not be started. shepherd: Service term-auto could not be started. ... is output by 'guix system reconfigure /etc/config.scm' after a 'guix pull' (both run as root). Output you requested: rs@anu ~$ sudo lsblk -p -o NAME,TYPE,FSTYPE,LABEL,UUID,MOUNTPOINT NAME TYPE FSTYPE LABEL UUID MOUNTPOINT /dev/sda disk └─/dev/sda1 part crypto_LUKS c396a60c-2c22-44eb-97f4-4d885d894782 └─/dev/mapper/root-part crypt ext4root-fs 8daae8f5-6dc0-4272-b615-fee947ba6a1e / rs@anu ~$ sudo /home/rs/.guix-profile/sbin/parted -l Model: ATA Samsung SSD 850 (scsi) Disk /dev/sda: 256GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start EndSize Type File system Flags 1 1049kB 256GB 256GB primary Also, my current /etc/config.scm is attached. Look forward to help on resolving these somewhat irritating errors. Regards sidhu1f On Sun, May 13, 2018 at 7:33 AM, Chris Marusich wrote: > sidhu1f writes: > >> ;; Assuming /dev/sdX is the target hard disk, and "my-root" >> ;; is the label of the target root file system. >> (bootloader (bootloader-configuration >>(bootloader grub-bootloader) >>(target "/dev/sda1"))) >> >> ;; Specify a mapped device for the encrypted root partition. >> ;; The UUID is that returned by 'cryptsetup luksUUID'. >> (mapped-devices >> (list (mapped-device >> (source (uuid "fe4039bc-d231-4943-9704-f8a1186e6d42")) >> (target "fs-root") >> (type luks-device-mapping >> >> (file-systems (cons (file-system >>(device "fs-root") >>(title 'label) >>(mount-point "/") >>(type "ext4") >>(dependencies mapped-devices)) >> %base-file-systems)) > > Can you also share the output of the following commands? > > sudo lsblk -p -o NAME,TYPE,FSTYPE,LABEL,UUID,MOUNTPOINT > sudo parted -l > > This will tell us how your disks, partitions, and LUKS volume are > configured. Hopefully that will make it easier to see why your > configuration isn't working. If you don't have those programs > available, you can install them with: > > guix package -i util-linux parted > > sidhu1f writes: > >> Hi Rekado >> >> On Sat, May 12, 2018 at 1:23 PM, Ricardo Wurmus wrote: >> >>> > I did discover something curious: my guix version seems unchanged >>> > even after multiple 'guix system reconfigure' invocations. I do >>> > believe I heeded the documentation to do a 'guix pull' before the >>> > first reconfigure. Still, invocations of 'guix', >>> > '/var/guix/profiles/system-1-link/profile/bin/guix --version' and >>> > '/var/guix/profiles/system-11-link/profile/bin/guix --version' >>> > all produce: >>> > >>> > guix (GNU Guix) 12e352dbcfc07b870c812999ae81c16f0aa8dc2c >>> > Copyright... >> >>> This is not as helpful as it may seem. The “guix” executable first >>> checks if ~/.config/guix/latest exists. If it does it will load modules >>> from there. It seems that you’ve used different guix executables, but >>> they would all load the same modules from ~/.config/guix/latest. >> >> I understand and accept what you are saying but it is not clear what >> it means in the current context. Do you mean that the guix version of >> Guix SD v0.14.0 fresh install, and the guix version after recently >> (couple of days back) doing a 'guix pull' and 'guix system >> reconfigure' being the same is expected behavior? By "guix version" >> above I mean the output displayed by 'guix --version'. > > The "guix" command is a thin wrapper that quickly delegates to whatever > you've installed in ~/.config/guix/latest. This is by design; it is how > we currently make it possible for multiple users to maintain separate > installations of Guix simultaneously. For a more detailed description > of how this works, you might find this email thread helpful: > > https://lists.gnu.org/archive/html/help-guix/2017-09/msg00092.html > > -- > Chris config.scm Description: Binary data
