mcron
nnI'm having trouble getting mcron to work. I have configured it in
/etc/config.scm similarly to the example given in the manual, but it the
mcron service seems to immediately stop. I've tried `sudo herd enable
mcron` and `sudo herd start mcron`, which work, but then when I check
its status, I find mcron is disabled and not running.
My /etc/config.scm looks like this:
`
;; This is an operating system configuration template
;; for a "desktop" setup with GNOME and Xfce where the
;; root partition is encrypted with LUKS.
(use-modules (gnu) (gnu services ssh) (gnu services mcron) (gnu system nss)
(gnu packages lisp) (gnu packages wm) (gnu packages linux)
(gnu packages guile) (gnu packages backup))
(use-service-modules desktop networking)
(use-package-modules certs gnome wm base idutils xorg)
(define updatedb-job
;; Run 'updatedb' at 3AM every day. Here we write the
;; job's action as a Scheme procedure.
#~(job '(next-hour '(3))
(lambda ()
(execl (string-append #$findutils "/bin/updatedb")
"updatedb"
"--prunepaths=/tmp /var/tmp /gnu/store"
(define garbage-collector-job
;; Collect garbage 5 minutes after midnight every day.
;; The job's action is a shell command.
#~(job "5 0 * * *";Vixie cron syntax
"guix gc -F 1G"))
(define idutils-job
;; Update the index database as user "charlie" at 12:15PM
;; and 19:15PM. This runs from the user's home directory.
#~(job '(next-minute-from (next-hour '(12 19)) '(15))
(string-append #$idutils "/bin/mkid src")
#:user "emacsomancer"))
(define mbsync-mail-fetch-emacsomancer
;; fetch mail via isync/mbsync for mu/mu4e every 10 minutes
#~(job "5/* * * * *" ;Vixie cron syntax
"/home/emacsomancer/.guix-profile/bin/mbsync -a"
#:user "emacsomancer"))
(define test-emacsomancer
;; fetch mail via isync/mbsync for mu/mu4e every 10 minutes
#~(job "1/* * * * *" ;Vixie cron syntax
"/home/emacsomancer/.guix-profile/bin/touch /home/emacsomancer/hello"
#:user "emacsomancer"))
(operating-system
(host-name "guixy")
(timezone "US/Mountain")
(locale "en_GB.utf8")
;; Use the UEFI variant of GRUB with the EFI System
;; Partition mounted on /boot/efi.
;; -> actually using BIOS because guixsd 0.15 live usb didn't probe efi
; (bootloader (grub-configuration (device "/dev/sda")))
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))
;; Specify a mapped device for the encrypted root partition.
;; The UUID is that returned by 'cryptsetup luksUUID'.
(mapped-devices
(list (mapped-device
(source (uuid "e33cc543-9aa9-467a-a9e8-96e1f092b866"))
(target "guiksdelux")
(type luks-device-mapping))
;; (mapped-device
;; (source (uuid "7c97b263-4adc-b4e9-a1d7-9d3de8eb9694"))
;; (target "guix-home")
;; (type luks-device-mapping))
))
(file-systems (cons* (file-system
(device (uuid "18c93271-4fcd-484b-ac1a-f4670b6d2b7c"
'ext4))
(mount-point "/")
(type "ext4"))
(file-system
(device "/dev/mapper/guiksdelux")
(mount-point "/home")
(type "ext4")
(dependencies mapped-devices))
; (file-system
;(device "/dev/mapper/guix-home")
;(mount-point "/home")
;(type "ext4")
;(dependencies mapped-devices))
; (file-system
; (device (uuid "35ee1733-b91f-4bbc-3bdc-86b5bd25489f"
'ext2))
; (mount-point "/boot")
; (type "ext2"))
; (file-system
; (device (uuid "F1D1-FC28" 'fat))
; (mount-point "/boot/efi")
; (type "vfat"))
%base-file-systems))
(users (cons (user-account
(name "emacsomancer")
;(comment "")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video"))
(home-directory "/home/emacsomancer"))
%base-user-accounts))
;; Add GNOME and/or Xfce---we can choose at the log-in
;; screen with F1. Use the "desktop" services, which
;; include the X11 log-in service, networking with
;; NetworkManager, and more.
(packages (cons* sbcl-stumpwm ;common lisp window manager
; awesome ;lua window manager
nss-certs ;for HTTPS access
gvfs ;for user mounts
xset ; no beeps &c.
tlp
Re: LUKS-encrypted root and unencrypted /boot ?
Benjamin Slade writes: > > 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.) > > 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. There are probably reasons I don't know about too :-) Good luck! Clément
Re: LUKS-encrypted root and unencrypted /boot ?
On 2018-08-02T02:24:31-0600, Chris Marusich wrote: > > Doing a full LUKS-encryption on root, including /boot results in > > very slow unlocking at boot (about 30 secs even with --iter set to > > 1000). Is there any way to do an unencrypted /boot with an > > encrypted root? > At that stage, is it GRUB that is unlocking the encrypted volume? If > so, I think this is normal. > For what it's worth, GRUB is slow in unlocking my encrypted volumes, > too. It takes about 30 seconds for me, too. If you're concerned, > you can try using cryptsetup's --iter-time option to lower the number > of iterations, but keep in mind that will also make it easier to > crack your passphrase. Originally I had --iter set to '5000' and it took about 4 minutes to unlock! I've shifted to using an unencrypted root and an encrypted /home as a compromise that boots faster (and only requests the password once). -- 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 ?
> Do you use Libreboot? Yes, I'm using Libreboot. Does this make a great difference over the manufacturer firmware in this case? > 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. -- 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: difficulty getting networking working on new install
> at the very least you could fire up a terminal and use "nmcli" or > "nmtui", which should be installed in your system profile by default > when you have the NetworkManager service installed. Thanks, Chris, this did help immensely. I've used other tools in the commandline and NetworkManager as an applet in the gui, but I've never used NetworkManager via the commandline and so I didn't even realise that the relevant applications were called "nmcli" & "nmtui" (I was trying to run `NetworkManager` in the terminal). (I wonder if this is worth throwing into the manual somewhere [unless it's there already and I missed it], since these seem to be the default networking tools included in the 'desktop package'.) -- 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: udev-rules for my FST-01 gnuk security token
> We do need a service for this. I'll write one if nobody beats me to > it. I have created a Guix service for pcscd. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32358 It looks like the udev rules were completely unnecessary for my gnuk token. Running the pcscd daemon alone was sufficient. Perhaps, it's the same for your nitrokey.
