Snamellit - guix

Install GUIX on Macbook 12

Peter Tillemans — Fri, 20 Mar 2026 11:01:00 +0100

Motivation</h2>
I have an old Intel macbook 12 of begin 2016, one of the so-called "Retina Macbooks". It is an ideal couch device but far too slow to run modern OS-X, provided you wanted to run that to begin with.</p>
I wanted to revive this machine to avoid lugging the BIG laptop, especially for the friday SystemCrafters stream in my comfy chair in the living.</p>
I saw some experience reports with Ubuntu, which worked, but then I never used it because Ubuntu is, well it is Ok, there is nothing wrong with it... Gnome works fine, KDE worked fine, it is just all different from my usual Arch/Guix machines for little added benefit.</p>
Because I was curious about immutable distros and leveraging containers like toolbox/flatpak I installed Fedora Silverblue. Again it is fine, Gnome is really luxurious on this machine. It all works well, but again different. Distributing the software between immutable host (which you have to reboot to make packages appear after install), flatpaks and toolbox containers works fine again, but inevitably causes friction when crossing the domains, e.g. Emacs. Nothing insurmountable. Also I am not impresssed by toolbox, it is simple, but it does nothing that distrobox does not seem to do better, while being less tied to the OS. I am not a fan of the dev container workflow, and Fedora Silverblue didn't sell it to me. Again in large deployments the balance might be different.</p>
AFAICT Guix offers (almost) the same immutability features and drawbacks but less pronounced. i.e. you do not have to reboot to make host software available in most cases. The diffferent profiles allow much more granular control with several half-way points to find the right balance of reproducability and creature comfort. Of course this is also means more opportunity to let it run out of control and create a confusing mess. In any case I can leverage the GUIX configuration of my servers and big laptop and ensure a consistent experience if I can get it on the lil' macbook and liberate it to fight another day.</p>

Installation Process</h2>
Installing Ubuntu and Silverblue learned me that there is nothing specially difficult for the intel mac. It kinda just works with some small caveats.</p>
A quick hardware check shows a BCM4350 wireless network adapter which is not on the open hardware list AFAIK, and since the laptop needs to do laptop duty and has only a single USB-C port WiFi is the only way to get something in and out of it. Intel graphics should not be a problem. An intel soundchip. Some Apple NVMe controller (foreshadowing)</p>
So we probably need the nonguix version to support the firmware blobs.</p>

Creating Installation Media</h3>

Check out on your local friendly Guix enabled device, a foreign install is fine, checkout the SystemCrafters Guix Installer Repo</a>. In the root of the project is a script build.iso</code>. Run it and have a walk outside or something. It takes a while. If you have no Guix enabled machine yet, you can download the last released version, which is over a year old, so the first guix pull</code> on the macbook will be epic... .</p>

You'll end up with a file guix-installer-202603162333.iso</code> with of course a probably newer timestamp is spacetime is behaving consistently in your locati This can be written to a thumb drive. Ensure you check with dmesg -w</code> which device the USB stick uses. On insertion you'll see</p>

$ sudo dmesg -w
</span>... lots of lines skipped
</span>[308042.889695] usb 1-4.3.2: new high-speed USB device number 12 using xhci_hcd
</span>[308043.000238] usb 1-4.3.2: New USB device found, idVendor=0781, idProduct=5572, bcdDevice= 1.00
</span>[308043.000242] usb 1-4.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
</span>[308043.000244] usb 1-4.3.2: Product: Cruzer Switch
</span>[308043.000246] usb 1-4.3.2: Manufacturer: SanDisk
</span>[308043.000247] usb 1-4.3.2: SerialNumber: 4C530001061011107340
</span>[308043.038906] usb-storage 1-4.3.2:1.0: USB Mass Storage device detected
</span>[308043.039031] scsi host2: usb-storage 1-4.3.2:1.0
</span>[308043.039112] usbcore: registered new interface driver usb-storage
</span>[308043.042575] usbcore: registered new interface driver uas
</span>[308044.049756] scsi 2:0:0:0: Direct-Access     SanDisk  Cruzer Switch    1.00 PQ: 0 ANSI: 6
</span>[308044.055625] sd 2:0:0:0: [sda] 62521344 512-byte logical blocks: (32.0 GB/29.8 GiB)
</span>[308044.056787] sd 2:0:0:0: [sda] Write Protect is off
</span>[308044.056790] sd 2:0:0:0: [sda] Mode Sense: 43 00 00 00
</span>[308044.057159] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
</span>[308044.093399]  sda: sda1 sda2
</span>[308044.093545] sd 2:0:0:0: [sda] Attached SCSI removable disk
</span></code></pre>
The '[sda]' on the last lines shows that the USB is now available as
/dev/sda</code>. Be careful as using your current harddisk by accident will
cause an unscheduled backup/restore excercise. To be safe make sure
you use the data which appeared on screen when inserting the
drive. Pull it out and insert it again to be sure.</p>
Also don't mount/open it if your smart desktop assistent comes asking
helpfully. It only makes things slower and more complicated.</p>
$ sudo dd if=guix-installer-202603162333.iso of=/dev/sda bs=1M
</span>$ sync
</span></code></pre>
The bs=1M</code> is to speed things up otherwise it takes forever. Value is
not critical but this is easy to type and _reasonable_™.</p>
This will probably take a refill coffee</span> amount of time to
complete. The `sync` should ensure the buffers are written before
unplugging the device.</p>
Installation Process</h3>
One of the biggest challenges to start the installation process is to
build a Jenga tower of USB dongles to ensure you can power the macbook
and insert the USB stick. This device only has a single USB-C port, it
dislikes thunderbolt docks or even many USB-C docks. I used a
Steamdeck dock. In practice I assume most of the cheap USB extender
dongles will do it, however I had to experiment before it worked.</p>
You can probably install the OS on whatever capacity is remaining
after all this time, but I would not rely on it and I would not want
to do the crypto setup of the disks with the battery draining like a
James Bond Villain Death Trap</a>.</p>
I installed it a few times. First without disk encryption. Worked
fine. You follow the prompts.</p>
Then with disk encryption. Worked fine.</p>
I choose separate volumes for root</code> and home</code> formatted in ext4. When encrypting the
volumes using LUKS we now get an interesting issue. During boot up we
are asked 4 times to unlock the drives. Also once we selected the
image to boot in Grub the kernel will ask to unlock the disks, but the
internal laptop keyboard does not work. This can be solved by adding a
USB keyboard to your Jenga Tower and unlock the drives. This get tired
really quickly. For installation it is not a blocker so we plod on.</p>
Also at some point the graphical installer decide that black is the
new orange and show nothing else than that. However the manual
installer is well documented.</p>
Also the installation process for GUIXSD is far less important than
for other distros as you can completely control the OS using `guix
system reconfigure`. So if you can boot in a terminal and get on your
network you're golden.</p>
Crypto Setup</h3>
I am going to forget the keyboard issue for now and deal with the
passwords. Because if that is fixed the keyboard does not matter
anymore as once the kernel is fully started it works again.</p>
If you followed along the installer will already have created the
partitioning and LUKS encryption of the volumes. We can use a keyfile
to unlock the partitions but we have to make sure the keyfile is not
exposed on an unencrypted volume. Some people suggest a keyfile on a
USB stick but this is not very practical on this device (think Jenga
tower).</p>
There is no way to pass secrets from Grub to the booting
kernel. However we have access to files in the initial ramdisk. The
GUIX bootloader configuration has the extra-initrd</code> option which was
originally added for this very purpose and adding the keyfile is
explained there.</p>
So the plan is:</p>

add a key from a keyfile to a slot in the LUKS partitions</li>
wrap the keyfile in a cpio image to merge to the initial ramdisk</li>
configure the mapped devices to use this keyfile</li>
</ul>
add keyfile to initrd</h4>
I created a random file</p>
$ dd if=/dev/urandom of=/keyfile.bin bs=1 count=512
</span>$ chmod 0400 /keyfile.bin
</span>$ echo /key-file.bin | cpio -oH newc >/key-file.cpio
</span>$ chmod 0000 /keyfile.cpio
</span></code></pre>
add the keyfile as a key to the LUKS partitions.</p>
Update /etc/config.scm</code> to add the extra-initrd</code> option to make the file
accessible during early boot.</p>
(bootloader (bootloader-configuration
</span>               (bootloader grub-efi-bootloader)
</span>               (targets '("/boot/efi"))
</span>               (keyboard-layout keyboard-layout)
</span>	              (extra-initrd "/key-file.cpio")))
</span></code></pre>
Tell kernel to use the keyfile</h4>
To configure the kernel to use the keyfile instead of asking for a
password, we have to add the #:key-file "/key-file.bin"</code> to the luks mapping</p>
(mapped-devices
</span> (list (mapped-device
</span>        (source (uuid "47642581-ea45-4c53-84c8-d1baf81c70de"))
</span>        (target "my-root")
</span>        (type luks-device-mapping)
</span>	        (arguments '(#:key-file "/key-file.bin")))
</span>       (mapped-device
</span>        (source (uuid "f2d3ee87-7cc7-4a95-8f4c-1f6c0fa750ee"))
</span>        (target "my-home")
</span>        (type luks-device-mapping)
</span>	        (arguments '(#:key-file "/key-file.bin")))))
</span></code></pre>
Apply it</h4>
run a guix system reconfigure</code> and reboot and now you will only have to
enter 2x the password. A 50% improvement  ( or 500%, 600% according to
some world leader).</p>
Now why does grub insist in decrypting the /home</code> partition?</p>
A quick look in /boot/grub/grub.cfg</code> shows:</p>
➜ cat /boot/grub/grub.cfg | head
</span># This file was generated from your Guix configuration.  Any changes
</span># will be lost upon reconfiguration.
</span>insmod luks
</span>insmod luks2
</span>cryptomount -u 47642581ea454c5384c8d1baf81c70de
</span>cryptomount -u f2d3ee877cc74a958f4c1f6c0fa750ee
</span>
</span># Set 'root' to the partition that contains /gnu/store.
</span></code></pre>
Ok, that explains it. But why?</p>
The manual does not give me any hints. Looking in the source code of
the guix bootloader generator shows that it makes a list of all mapped
devices which have a valid UUID and add it to grub. It throws a
warning when a mapped device uses the regular linux devicename instead
of the UUID as grub cannot find the devices with the linux name. This
makes sense and we can abuse it to get rid of the 2nd password prompt:</p>
(mapped-devices
</span> (list (mapped-device
</span>        (source (uuid "47642581-ea45-4c53-84c8-d1baf81c70de"))
</span>        (target "my-root")
</span>        (type luks-device-mapping)
</span>	  (arguments '(#:key-file "/key-file.bin")))
</span>       (mapped-device
</span>        ;;(source (uuid "f2d3ee87-7cc7-4a95-8f4c-1f6c0fa750ee"))
</span>	  (source "/dev/nvme0n1p3")
</span>        (target "my-home")
</span>        (type luks-device-mapping)
</span>	  (arguments '(#:key-file "/key-file.bin")))))
</span>
</span></code></pre>
If we replace the UUID with the regular device name, it will no longer
be exported to grub.cfg</code> and the kernel kan still find the device for
mapping it.</p>
A quick reconfigure and reboot later confirms this. I can now remove
the keyboard from the Jenga tower, but that would be cheating.</p>
Fixing the keyboard</h3>
Some searching in the Guix mailing list showed that "hid_apple" was
removed from the standard initrd somewhere in '24 because of issues
with RISCV.</p>
That is where the initrd-modules</code> option is for:</p>
(operating-system
</span>  ...
</span>  (initrd-modules (cons "hid_apple" %base-initrd-modules))
</span>)
</span></code></pre>
This fixes the issue. I forgot how I tested it, but it does.</p>
Post Installation</h2>
System does not allow to login after sleep</h3>
Actually the problem is that the disk is still sleeping (remember the
foreshadowing when seeing the Apple NVMe device). This is not GUIX
specific as I already had to fix it in Ubuntu and Fedora. There you
add</p>
echo 0 >/sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowed
</span></code></pre>
in the crontab</code> on the @reboot</code> event.</p>
This syntax is not supported by the herd scheduled jobs and I did not
find an alternative and got no suggestions on the #guix IRC
channel. So I decided to make a small shepherd service for this.</p>
(define disk-sleep-shepherd-service
</span>  (shepherd-service
</span>   (provision '(disk-sleep))
</span>   (documentation "Disallow disk to go to d3cold state to prevent crash on wake up.")
</span>   (one-shot? #t)
</span>   (start #~(lambda _
</span>	       (call-with-output-file "/sys/bus/pci/devices/0000:01:00.0/d3cold_allowed"
</span>		 (lambda (port) (display "0" port)))
</span>	       #t))))
</span>
</span>
</span></code></pre>
The only part I struggled with is that the start</code> field takes a
function with a variable number of arguments. The /var/log/messages</code>
registered the error but was not very helpful. Herd did not show the
service at all until it was fixed. Comparing to other implementation
gave the needed clues.</p>
To add this to the system:</p>
(operating-system
</span> ...
</span> (services
</span>  ...
</span>  (simple-service 'disk-sleep-service shepherd-root-service-type
</span>	  (list disk-sleep-shepherd-service))
</span>  ...
</span>  ))
</span></code></pre>
Sound : no sound from speakers.</h3>
There is no sound coming from the speakers.</p>
There is sound coming from the headphone jack. Good enough for use in
the living.</p>
I'll call this a feature, not a bug.</p>
Things I would do differently</h2>
Basically use btrfs to have a single encrypted LUKS volume to deal with and
split the volumes in btrfs. That would also give the other goodness of
btrfs and should be well supported by grub.</p>
But for now I'll enjoy my new couch laptop.</p>


Screenshot in Sway with GUIX
Peter Tillemans — Sat, 25 Oct 2025 14:19:00 +0200
Screenshots in Sway with Guix Home Manager</h2>
A blog post</a> documented an elegant way to configure screenshots in
wayland using grim</strong> and grimshot</strong>. After moving my sway config to use
the GUIX</strong> sway-service</code> to generate the config file Iost my configured
screenshot bindings.</p>
Output Files</h3>
The screenshots will be placed  in the Pictures/screenshots</code> folder
with the timestamp as filename.  To avoid duplication and ensure
consistency we'll add  a variable to generate the filename</p>
(sway-configuration
</span>  (variables (append %sway-default-variables
</span>		     `((menu .  ,#~(string-append
</span>                                    #$fuzzel
</span>                                    "/bin/fuzzel"
</span>                                    " -w 50 -x 8 -y 8 -r 3 -b 232635ff -t A6Accdff -s A6Accdff -S 232635ff -C c792eacc -m c792eacc -f \"JetBrains Mono:weight=light:size=10\" --icon-theme=\"Papirus-Dark\" --no-exit-on-keyboard-focus-loss"))
</span>		       (term . ,(file-append alacritty "/bin/alacritty"))
</span>		       (screenshot_out . "$(xdg-user-dir PICTURES)/screenshots/$(date +\"%Y%m%d-%H%M%S\").png"))
</span>		     ))
</span>  ...)
</span></code></pre>
Key Bindings</h3>
I often use various screenshots pasted in chat windows or Jira tickets
so the clipboard is an important destination.
Alternatively saving them to move them to a target folder for
inclusion whereverr they needed is an important secondary use-case.</p>
We can now use the variable made previously and add the following keybindings:</p>
(sway-configuration
</span>	    ...
</span>	    (keybindings (append
</span>			  `(...
</span>			    ;; Special key to take a screenshot with grim
</span>			    ($mod+Shift+p . "exec grimshot copy anything")
</span>			    ($mod+Shift+s . "exec grimshot save screen $screenshot_out")
</span>			    ($mod+Shift+w . "exec grimshot save window $screenshot_out")
</span>			    ($mod+Shift+a . "exec grimshot save area $screenshot_out")
</span>			    ...
</span>
</span>			    )
</span>
</span>
</span></code></pre>
Deploying the configuration</h2>
To activate the configuration</p>
$ make home
</span>echo Loading modules from ~/.config/dotfiles/guix/src
</span>Loading modules from /home/pti/.config/dotfiles/guix/src
</span>guix home reconfigure -L ~/.config/dotfiles/guix/channel -c 32 ~/.config/dotfiles/guix/home-config-`hostname | cut -d. -f1`.scm
</span>...
</span></code></pre>
which quickly (for some value of quick) updates the home
configuration, writing a new ~/.config/sway/config</strong> file.</p>
When the prompt returns a quick reload of the sway config with
$mod+Shift+c</code> and testing if the modifications are active.</p>
Testing it Out</h2>
I opened libre office writer to paste copied screenshots and made a
mess to show the copy anything</code> works as expected. It does, it
highlights what it understands depending on your mouse location, a
window if hovering over a window, a rectangle if you start selecting
and all the screen if you move the mouse outside all windows (i.e. the
boundary on a tiling wm). It is a bit fiddly so sometimes I select the
wrong thing, but since it only clobbers the clipboard and I can
quickly try again, this seems reasonable.</p>
Similarly using the 3 other bindings to save different type of
screenshots.</p>
  $ ls ~/Pictures/screenshots/
</span>20251025-141106.png  20251025-145006.png  20251025-145019.png
</span></code></pre>
Cool, that made a mess in the folder and displaying</strong> them show that it
are actually screenshots. Cool.</p>


Samba Adventures with Guix
Peter Tillemans — Sat, 17 Aug 2024 00:00:00 +0200
Samba or CIFS file sharing is a finicky area at best, but widely used,
especially since it was heavily pushed by Microsoft in the Windows
ecosystem, This makes it widely used in corporate and NAS environments
and even for Linux file sharing.</p>
In this post I will look at some ways to use CIFS file sharing as a
client. Personally I find hardly any uses for Samba file serving
nowadays from my compute environments, with git</strong>, ssh</strong>, http(s)</strong>,
databases, MQTT, file synchronization services ... it hardly ever happens that
I face a situation where I think : "Hey, I wish I could serve my files
from my PC/VPS/VM/... with Samba". It is such a generic non-specific
service I usually find a more opinionated data sharing
service. Actually I find the same for NFS.</p>
That being said, it is still ubiquitous to get enterprise data and to
connect to NAS or remote hard disks.</p>
CIFS Server Simulator</h2>
In practice setting up and connecting to a CIFS server is a
frustrating experience due to a bewildering array of different
protocols, security systems, credentials, ... .</p>
To test out accessing a Samba server without having to deal with too
many moving pieces at the same time I like to use a known fixed local
basic samba server. This enables me to get working client - server
configurations which I find easier to tweak to real life servers than
starting from scratch.</p>
Docker hub provides preconfigured images for Samba servers which are
easy to use :</p>
$</span> docker run --name test-smb -p 4139:139 --rm -p 4445:445 -v `</span>pwd</span>`/samples/:/mnt/export --rm -d dperson/samba -p -u </span>"joe;schmoe"</span> -s </span>"export;/mnt/export/;yes;no;no;joe;;;Test Share"
</span></code></pre>
This will start a samba server and listen on ports 4139 and 4445 so it
does not clash if a server is running on the machine we're using and
we do not need special privileges other than being in the docker</code> group
to run docker</strong> as a regular user. The -s ...</code> option configures a share
name export</strong> which is browsable, not readonly, not accessible by guest
users and  can only be accessed with the joe</strong> user account. This is to
make the experience a bit more in line with usual real world
configuration which are seldom as open as the default settings for
shares. For more details, see the github repo for the image</a>.</p>
Because this is not a fun command line to type I like to put them in a
Makefile</strong> in a folder with some support files</p>
$</span> cd ...
</span>$</span> mkdir test-smb
</span>$</span> cd test-smb
</span>$</span> mkdir samples
</span>$</span> echo </span>"Hello, Samba" </span>></span>samples/hello.txt
</span></code></pre>
and then add the Makefile</p>
servers-start</span>:
</span>        </span>docker</span> run --name test-smb -p 4139:139 --rm -p 4445:445 -v `</span>pwd</span>`/samples/:/mnt/export --rm -d dperson/samba -p -u </span>"joe;schmoe"</span> -s </span>"export;/mnt/export/;yes;no;no;joe;;;Test Share"
</span>
</span>servers-stop</span>:
</span>        </span>docker</span> stop test-smb
</span></code></pre>
Guix Notes for Docker</h3>
Docker  (and podman too) need some OS support to talk to the kernel to
create the namespaces to make the containers work. Even though podman
does not need a daemon to run, it still needs some setuid</strong> helpers. I
tend to mostly use docker</strong> because of habit and everyone else uses it
and tends to be better supported and documented for my use cases. In
any case I did not have any luck getting either to work in a local
guix shell</code>.</p>
To enable docker</strong> on Guix-SD I have the following in my system configuration.</p>
  ...
</span>  (use</span>-</span>service</span>-</span>modules cups desktop docker networking ssh xorg)
</span>  ...
</span>
</span>(operating</span>-</span>system
</span>  ...
</span>  (users
</span>   (</span>cons</span>*
</span>    (user</span>-</span>account
</span>     ...
</span>     (supplementary</span>-</span>groups
</span>      '( ... </span>"docker"</span>)))  </span>;; enable access to docker daemon
</span>    %base</span>-</span>user</span>-</span>accounts))
</span>...
</span>(packages
</span> (</span>append
</span>  (</span>list
</span>   ...
</span>   </span>;; add docker command line tools
</span>   docker
</span>   ...
</span>   ))))
</span>...
</span>(services
</span> (</span>append
</span>  (</span>list
</span>   ...
</span>   </span>;; enable docker
</span>   (service docker</span>-</span>service</span>-</span>type)
</span></code></pre>
When using Guix on a host os, the native docker</strong> package should work
fine.</p>
Connecting using smbclient</h2>
Before mounting drives we need to ascertain our credentials are
accepted by the Samba server. It makes no sense proceeding trying to
mount shares if we cannot get past authentication and the overhead of
configuring those shares and the Guix configuration rebuilding really
impacts iteration speed when trying things out.</p>
The most straightforward way to connect to a CIFS server is with the
smbclient</strong> tool which is part of the samba</strong> package:</p>
➜</span> guix shell samba
</span>
</span>test-smb</span> on  main via 🐃
</span>➜</span> smbclient -L //localhost -p 4445 -U joe
</span>Password</span> for </span>[</span>WORKGROUP</span>\j</span>oe</span>]</span>:
</span>
</span>    </span>Sharename</span>       Type      Comment
</span>    </span>---------</span>       ----      -------
</span>    </span>export          </span>Disk      Test Share
</span>    </span>IPC$</span>            IPC       IPC Service (Samba Server)
</span>SMB1</span> disabled</span> --</span> no workgroup available
</span>
</span>test-smb</span> on  main </span>[!]</span> via 🐃  took 4s
</span>➜</span> smbclient //localhost/export -p 4445 -U joe
</span>Password</span> for </span>[</span>WORKGROUP</span>\j</span>oe</span>]</span>:
</span>Try </span>"help"</span> to get a list of possible commands.
</span>smb: </span>\></span> ls
</span>  </span>.</span>                                   D        0  Sat Aug 17 03:49:32 2024
</span>  </span>..</span>                                  D        0  Sat Aug 17 05:22:38 2024
</span>  </span>hello.txt</span>                           N       13  Sat Aug 17 03:50:27 2024
</span>
</span>                </span>1912951596</span> blocks of size 1024. 998957000 blocks available
</span>smb: </span>\>
</span></code></pre>
The guix shell samba</code> creates a profile with the samba</strong> package
installed which places `smbclient` on the path.</p>
smbclient -L //servername</code> lists the services offered by the server, in
our case localhost</strong> to connect to our docker instance. The -p 4445</code>
option selects the custom port we specified on our docker
container. By default smbclient</strong> will use your login as uid, so we need
to override it to the user we created when starting the docker
container with -U joe</code> .</p>
The password is configured as schmoe</code>.</p>
We see the export</code> folder is shared so we connect to it using
`smbclient //localhost/export -p 4445 -U joe` and can list the
contents. And of course we can upload, download and all the other
terminal goodness offered by smbclient</strong>.</p>
In practice it can be very fiddly to get the right username, password,
Workgroup or Domain, port number, SMB protocol, etc dialed in. The
obtuse messages often do not really help. The other methods make
interpreting errors even harder, with the exception of programmatic
access which is sometime surprisingly helpful in getting a connection
going.</p>
Save the credentials</h3>
The samba tools have a convention to save the credentials in a
authentication file</strong> which is supported by most tools AFAICT.</p>
To use this create a file .smbcredentials</code> in your home folder. Well,
it can be anything but I like that place as I typically only have my
NAS to connect to using samba and it is for my home folder, backup
folder, my Music and Movies folder and the like, i.e. stuff related to
my user account, so I find it in its place in my home folder.</p>
In it place the username</code>, password</code> and domain</code> which worked with
smbclient so they no longer need to be provided :</p>
username=joe
</span>password=schmoe
</span>domain=WORKGROUP
</span></code></pre>
Then we can use it:</p>
$</span> smbclient //localhost/export -p 4445 -A </span>~</span>/.smbcredentials
</span>
</span>Try </span>"help"</span> to get a list of possible commands.
</span>smb: </span>\></span> ls
</span>  </span>.</span>                                   D        0  Sat Aug 17 03:49:32 2024
</span>  </span>..</span>                                  D        0  Sat Aug 17 12:02:13 2024
</span>  </span>hello.txt</span>                           N       13  Sat Aug 17 03:50:27 2024
</span>
</span>                </span>1912951596</span> blocks of size 1024. 998918312 blocks available
</span>smb: </span>\>
</span></code></pre>
This save a lot of typing and we can use this file in the next stages
and avoid spreading the credentials all over the disk. I am going to
gloss over encrypting this info any further because I do not keep
nuclear (or any other for that matter) secrets on my nas.</p>
Mounting Shares with mount.cifs</code></h2>
Let's create a mount point in our test folder</p>
$</span> mkdir mnt
</span></code></pre>
and then mount the share with mount.cifs</code>.  This is part of the cifs-utils</code> package.</p>
ttest-smb</span> on  main </span>[?]</span> via 🐃
</span>➜</span> guix shell cifs-utils
</span>The</span> following derivation will be built:
</span>  </span>/gnu/store/2x7mmyrsnsf21aing02ass82899gm2yh-profile.drv
</span>
</span>building</span> CA certificate bundle...
</span>listing</span> Emacs sub-directories...
</span>building</span> fonts directory...
</span>building</span> directory of Info manuals...
</span>building</span> profile with 1 package...
</span>est-smb</span> on  main via 🐃
</span>❮</span> sudo mount.cifs //localhost/export mnt -o credentials=/home/pti/.smbcredentials,port=4445
</span>
</span>test-smb</span> on  main </span>[?]</span> via 🐃
</span>➜</span> ls mnt
</span>hello.txt
</span>
</span>test-smb</span> on  main </span>[?]</span> via 🐃
</span>➜
</span></code></pre>
This mounts the share to the folder mnt</code>. The -o</code> option is used to
point to the credentials file and the port number of our docker NAS
simulator.</p>
Checking with the regular mount</code> command to see if it agrees we mounted
the share:</p>

</span>❯</span> sudo mount -t cifs
</span>//localhost/export</span> on /home/pti/src/test-smb/mnt type cifs (rw,relatime,vers=3.1.1,cache=strict,username=joe,domain=WORKGROUP,uid=0,noforceuid,gid=0,noforcegid,addr=0000:0000:0000:0000:0000:0000:0000:0001,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1)
</span>
</span>test-smb</span> on  main </span>[?]</span> via 🐃
</span>➜</span> sudo mount </span>| </span>grep</span> cifs
</span>/etc/auto.cifs</span> on /nas type autofs (rw,relatime,fd=6,pgrp=1732,timeout=600,minproto=5,maxproto=5,indirect,pipe_ino=27049)
</span>//localhost/export</span> on /home/pti/src/test-smb/mnt type cifs (rw,relatime,vers=3.1.1,cache=strict,username=joe,domain=WORKGROUP,uid=0,noforceuid,gid=0,noforcegid,addr=0000:0000:0000:0000:0000:0000:0000:0001,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1)
</span></code></pre>
Calling mount</code> without arguments lists all mounted filesystems, however
nowadays the output is so overwhelming that I prefer to use grep</code> to
narrow down the output to the filesystem type I am interested in. The
same thing can be achieved by specifying the filesystem type with the
-t</code> option.</p>
Configuring the mounts in the operating system.</h2>
The mount.cifs</code> command is fine for testing and ad-hoc use but in
practice I mostly (read 99+% of the time) want the same shares of the
NAS mounted in the same place on my system. This is where the fstab</code>
file comes in. This file is read by the mount command at boot time and
mounts the configured filesystems.</p>
I do not recommend mounting CIFS shares at boot time, but configuring
the shares in fstab</code> is a good way to be able to mount them when needed
with a quick mount -a</code> command.</p>
On my Tuxedo system I have in the /etc/fstab</code> file</p>
...
</span>//nas.snamellit.com/home /home/pti/nas   cifs   rw,uid=1000,gid=100,credentials=/home/pti/.smbcredentials   0   0
</span>//nas.snamellit.com/public /mnt/public   cifs   rw,uid=1000,gid=100,credentials=/home/pti/.smbcredentials   0   0
</span>//nas.snamellit.com/multimedia /mnt/multimedia   cifs   rw,uid=1000,gid=100,credentials=/home/pti/.smbcredentials   0   0
</span>...
</span></code></pre>
The first column is the reference to the share as we've seen
above. Then the mount point. The 3rd column indicates it is a cifs</code>
share, Then the options we've seen with smbmount. Here I have to play
with the uid</code> and gid</code> to align my local user and group with the
configuration on the nas. The last 2 columns are whether to include
the mounts when dumping the filesystem and doing a filesystem check
which will probably always be 0 as the CIFS server is responsible for
that.</p>
In theory this will mount the shares at boot time, and it probably
does, however in my experience it seems they are unmounted on suspend
and not remounted after resume. Or there is some timeout. I never
investigated I must admit. I just do a quick mount -a</code> before I need
them and this works wonders.</p>
On Guix-SD the file-systems</code> are specified in the operating-system</code>
section of the system configuration :</p>
(operating</span>-</span>system
</span> ...
</span>
</span>(file</span>-</span>systems
</span> (</span>cons</span>*
</span>  ...
</span>  (file</span>-</span>system
</span>    (device </span>"//nas.snamellit.com/public"</span>)
</span>    (options </span>"uid=1000,gid=1000,credentials=/home/pti/.smbcredentials"</span>)
</span>    (mount</span>-</span>point </span>"/mnt/public"</span>)
</span>    (type </span>"cifs"</span>)
</span>    (mount? #f)
</span>    (create</span>-</span>mount</span>-</span>point? #t))
</span>  (file</span>-</span>system
</span>    (device </span>"//nas.snamellit.com/multimedia"</span>)
</span>    (options </span>"uid=1000,gid=1000,credentials=/home/pti/.smbcredentials"</span>)
</span>    (mount</span>-</span>point </span>"/mnt/multimedia"</span>)
</span>    (type </span>"cifs"</span>)
</span>    (mount? #f)
</span>    (create</span>-</span>mount</span>-</span>point? #t))
</span>  (file</span>-</span>system
</span>    (device </span>"//nas.snamellit.com/home"</span>)
</span>    (options </span>"uid=1000,gid=1000,credentials=/home/pti/.smbcredentials"</span>)
</span>    (mount</span>-</span>point </span>"/home/pti/nas"</span>)
</span>    (type </span>"cifs"</span>)
</span>    (mount? #f)
</span>    (create</span>-</span>mount</span>-</span>point? #t))
</span>  %base</span>-</span>file</span>-</span>systems)))
</span> </span>)</span>
</span></code></pre>
Which is just a straightforward translation of the fstab</strong> columns in
Guix-ese.</a></p>
Automatic Mounting with AutoFs</h2>
Of course the inefficiency of having to type mount -a</code> almost on a
weekly basis is unbearable and this inefficiency has to be addressed
even if this means we cannot expect net positive effect in the coming
millenia.</p>
Enter autofs</code> which is an awesome system to dynamically mount and
unmount filesystems on an as needed basis. The kernel will notice when
a mounted folder is accessed and ask the autofs daemon</strong> to mount the
configured mount and unmount it after some timeout occurs without any
activity.</p>
This is transparant for the user other than a slight delay when
accessing the folder the first time when it is unmounted.</p>
This system is very flexible at it was clearly intended for far more
ambitious use-cases than accessing your personal music library from
your nas, but that does not mean we cannot strip it down and use it
for our purposes.</p>
What is a bit confusing is the configuration. It uses 3 different
file types to configure the system.</p>

the /etc/autofs.conf</code> file which configures the daemon operating
options, like the timeouts and the location of the main master file</strong>.</li>
the master file(s), there is always a main file, but this can
delegate to directory with additional parts of the file which can be
assumed to be imported in the main file. Its main purpose is to map
a parent folder of mount points to a map file</strong>.</li>
the map files which map a subfolder in the folder from the line in
the master file</strong> to a mount specification which will be used when
that folder is accessed.</li>
</ul>
Example on the Tuxedo:</h3>
On my Tuxedo (running Tuxedo OS which is an Ubuntu 22.04 derivate) I have the following configuration:</p>


/etc/autofs.conf</code>:</p>
...
</span>[ autofs ]
</span>#
</span># master_map_name - default map name for the master map.
</span>#
</span>master_map_name = /etc/auto.master
</span>...
</span></code></pre>
so the master map</strong> is in the file /etc/auto.master</code>.</p>
</li>

/etc/auto.master</code>:</p>
...
</span>/-  /etc/autofs.direct  -ro
</span></code></pre>
</li>
</ul>
The "/-" is a special case which means "any" directory. In this case
the folder name in the map file</strong> is assumed to be a fully qualified
directory name instead of a subfolder in the folder mentioned in the
first column.  In this case the map file</strong> is /etc/autofs.direct</code> and the
default options are -ro</code> .</p>

/etc/autofs.direct</code>:/home/pti/nas -fstype=cifs,rw,noperm,vers=3.0,credentials=/home/pti/.smbcredentials    ://nas.snamellit.com/home
</span></code></pre>
This shows that the mount point /home/pti/nas</code> will mount the share
//nas.snamellit.com/home</code> of file system type cifs with the options
(the rest of the 2nd column) as mount options.</li>
</ul>
Example on the Guix-SD desktop</h3>
Unfortunately there is not (yet) packaged support for an autofs</strong>
service-type, so we have to make it ourselves.</p>
First we define a configuration record type for our new service:</p>
(define</span>-</span>record</span>-</span>type</span>* <</span>autofs</span>-</span>configuration</span>>
</span>  autofs</span>-</span>configuration make</span>-</span>autofs</span>-</span>configuration
</span>  autofs</span>-</span>configuration?
</span>  (pid</span>-</span>file autofs</span>-</span>configuration</span>-</span>pid</span>-</span>file
</span>            (default </span>"/var/run/autofs.pid"</span>))
</span>  (autofs</span>-</span>direct autofs</span>-</span>configuration</span>-</span>autofs</span>-</span>direct
</span>                 (default (plain</span>-</span>file </span>"autofs.direct" "/home/pti/autonas -fstype=cifs,rw,noperm,vers=3.0,credentials=/home/pti/.smbcredentials  ://nas.snamellit.com/home"</span>))))
</span></code></pre>
I should probably not put my actual configuration in the default, but
it makes my life easier at the moment and I'll refactor it
later. (Yeah, sure...)</p>
Since the autofs service needs some boilerplate configuration files I
generate them with an activation function:</p>
(define (autofs</span>-</span>activation config)
</span>  </span>"Return the activation GEXP to create the config files for autofs"
</span>  (</span>with-</span>imported</span>-</span>modules '((guix build utils))
</span>                         #~(begin
</span>                             (use</span>-</span>modules (guix build utils)
</span>                                          (ice</span>-</span>9</span> textual</span>-</span>ports))
</span>
</span>                             (define (touch file</span>-</span>name)
</span>                               (call</span>-with-</span>output</span>-</span>file file</span>-</span>name (const #t)))
</span>
</span>                             </span>;; 'sshd' complains if the authorized-key directory and its parents
</span>                             </span>;; are group-writable, which rules out /gnu/store.  Thus we copy the
</span>                             </span>;; authorized-key directory to /etc.
</span>                             (call</span>-with-</span>output</span>-</span>file </span>"/etc/autofs.conf"
</span>                               (</span>lambda </span>(</span>f</span>) (put</span>-</span>string f </span>"
</span>[ autofs ]
</span>master_map_name = /etc/auto.master
</span>timeout = 300
</span>"</span>)))
</span>                             (call</span>-with-</span>output</span>-</span>file </span>"/etc/auto.master"
</span>                               (</span>lambda </span>(</span>f</span>) (put</span>-</span>string f </span>(</span>format </span>#f </span>"/-  ~a -ro</span>\n</span>"</span> #$(autofs</span>-</span>configuration</span>-</span>autofs</span>-</span>direct config)))))
</span>
</span>                             )))
</span></code></pre>
You'll recognize the absolutely stripped down versions of the files
mentioned above being generated. The /etc/auto.master</code> file maps the
directfs</strong> map file to the file generated in the configuration record.</p>
This should tie up nicely the links between the 3 files.</p>
Then I need a shepherd service</strong> to start the autofs</strong> daemon:</p>
(define (autofs</span>-</span>shepherd</span>-</span>service config)
</span>  (define pid</span>-</span>file (autofs</span>-</span>configuration</span>-</span>pid</span>-</span>file config))
</span>
</span>  (</span>list
</span>   (shepherd</span>-</span>service
</span>    (provision '(autofs))
</span>    (</span>documentation </span>"AutoFS Service."</span>)
</span>    (requirement '(networking))
</span>    (start #~(make</span>-</span>forkexec</span>-</span>constructor
</span>              (</span>list
</span>               #$(file</span>-</span>append</span> autofs </span>"/sbin/automount"</span>)
</span>               </span>"-f" </span>;; run in foreground to give shepherd more control
</span>               </span>"-p"</span> #$(autofs</span>-</span>configuration</span>-</span>pid</span>-</span>file config)
</span>               </span>"/etc/auto.master"</span>)
</span>              #:pid-file #$(autofs</span>-</span>configuration</span>-</span>pid</span>-</span>file config)))
</span>    (stop #~(make</span>-</span>kill</span>-</span>destructor))
</span>    )))
</span></code></pre>
We point it to the generated auto.master</strong> file from the activation
function. (I could probably refactor this to use guix instantiated
files but at this stage that extra level of indirection would only
confuse me and make debugging harder. I find jumping through 3 files
already hard enough to follow).</p>
Then we need to put a bow around it and define an autofs-service-type</code>.</p>
(define autofs</span>-</span>service</span>-</span>type
</span>  (service</span>-</span>type (name 'autofs)
</span>                (description </span>"Run the autofs daemon to automount folders on access."</span>)
</span>                (extensions
</span>                 (</span>list
</span>                  (service</span>-</span>extension activation</span>-</span>service</span>-</span>type autofs</span>-</span>activation)
</span>                  (service</span>-</span>extension shepherd</span>-</span>root</span>-</span>service</span>-</span>type autofs</span>-</span>shepherd</span>-</span>service)))
</span>                (compose </span>concatenate</span>)
</span>                (default</span>-</span>value (autofs</span>-</span>configuration)))
</span>  )
</span></code></pre>
This just extends the activation-service-type</code> and the
shepherd-root-service-type</code> to run our initialisation code and ensure
the autofs</strong> daemon gets started.</p>
Then we can add this to our system configuration:</p>
(operating</span>-</span>system
</span> ...
</span> (packages
</span>  (</span>append
</span>   (</span>list
</span>    ...
</span>    autofs)))
</span> (services
</span>  (</span>append
</span>   (</span>list
</span>    ...
</span>    (service autofs</span>-</span>service</span>-</span>type))
</span>   ...)))
</span></code></pre>
i.e. add the autofs</code> package to install the daemon and support stuff
and enable the service of type autofs-service-type</code>.</p>
Conclusion</h2>
I can now use files on my nas transparantly. I was a bit flippant on
my reasons to enable autofs</strong>. The real reason was that I want to keep
automatic backup copies of my forge running on an VPS somewhere on my
NAS with a cron job, which means I would not be there to run a mount -a</code> at the time. (I now realize I could do that as part of the cron
job : 20/20 hindsight). In any case this is a major quality of life
improvement. As a side effect, my music library now gets properly
indexed and is made available on the default music player. Apparently
I still use CIFS more than I care to admit.</p>
The big problem with SMB/CIFS is getting the initial connection
going. Once that is achieved and the credentials are safely stored
away in credentials</strong> file, they can be easily reused with a lot less
surprising things along the way.</p>
It also pays to test things out in the smallest possible meaningful
scope, in this case smbclient</strong> before adding more obfuscation layers on
top of it, as that just adds more complexity, pitfalls and rabbit
holes to get lost in. By going step by step, building on previous
result I often get results faster (or at all) even if I have to do
additional steps which turn out to no longer be needed in the final
solution.</p>


Workflows for Unix Password Store with Emacs and Shell
Peter Tillemans — Tue, 25 Jun 2024 00:00:00 +0000
Table of Contents</h1>

Managing Secrets using Pass</a></li>
Installation</a>

GUIX</a></li>
Debian, Ubuntu et al</a></li>
</ol>
</li>
Emacs Integration</a>

Enable the Unix Password Store.</a></li>
Helper Function</a></li>
Using in Emacs Configuration</a></li>
</ol>
</li>
Shell integration</a>

DirEnv integration</a></li>
</ol>
</li>
Tips</a>

Entering passwords on the terminal</a></li>
Getting fields from multi field secrets</a></li>
</ol>
</li>
</ol>
</a></p>
Managing Secrets using Pass</h1>
On UNIX there is a well known tool to manage secrets called
password-store</strong> or pass</strong> for short.</p>
It is a very minimal tool, more to facilitate workflows that to do
real work, very much in the UNIX philosophy. It stores all secrets in
plain files in a folder structure. It does not care about what is in
the files and encrypts them using a GPG public key so only the owner
of the private key can decrypt them. It does offer special access to
the first line so a password can be quickly fetched and copied to the
clipboard or stdout or wherever some pass</strong> aware integration needs it.</p>
Certain folders can be configured to use a different public keys to
allow pragmatic secret delegation to different systems without
exposing all secrets.</p>
It leverages the gpg</strong> infrastructure for key management, distribution,
unlocking with pinentry</strong>, caching with gpg-agent</strong>.</p>
</a></p>
Installation</h1>
</a></p>
GUIX</h2>
Add password-store</strong>, gpg</strong> and pinentry</strong> to your package list.</p>
The pinentry</strong> program provides a client to securely unlock your keys in
a GUI and terminal environment. There are other options to make it
better fit your environment, but this is fine for me.</p>
</a></p>
Debian, Ubuntu et al</h2>
Add pass</strong>, gpg</strong>, gpg-agent</strong> and pinentry-gnome</strong> of pinentry-qt</strong> using</p>
$ apt-get install pass gpg gpg-agent pinentry-qt
</span></code></pre>
Both the gnome and qt versions at least fall back gracefully if no
graphical environment are available.</p>
The current selected pinentry program is provided as
/usr/bin/pinentry</strong> and this link is managed by the usual alternatives
machinery in debian based distros.</p>
</a></p>
Emacs Integration</h1>
Emacs auth-source</strong> infrastructure supports pass</strong> out of the box.</p>
</a></p>
Enable the Unix Password Store.</h2>
We have to make sure the password-store is added to the
auth-sources. There is a handy function for that:</p>
;; enable unix password-store
</span>(auth-source-pass-enable)
</span></code></pre>
We add that somewhere in the init.el before any secrets are needed.</p>
</a></p>
Helper Function</h2>
Auth-sources is a flexible system and works like a database, i.e. you
can query, browse through results and have multiple fields per secret.</p>
Example:</p>
(defun snam-password (host user)
</span>  "Get password from the unix password store.
</span>
</span>Searches the password file for a secret in the folder corresponding to
</span>the HOST name given, which is the folder with the '/' replaced by a '.'.
</span>The filename in the folder corresponds to the USER argument with a
</span>'.pgp' extension."
</span>  (auth-info-password
</span>   (car (auth-source-search
</span>         :max 1
</span>         :host host
</span>         :user user))))
</span></code></pre>
`auth-source-search` returns a list of results, so we have to get the
first entry with `car`. The secret is lightly obfuscated, hence the
need to decode it with the `auth-info-password` function.</p>
Luckily there is a function auth-source-pass-get</a> to get a password
from the password store which also follows the recommended conventions
for multiple fields in a pass file.</p>
(auth-source-pass-get 'secret "snamellit/znc")
</span></code></pre>
The pseudo key `'secret` returns the first line of the password store
entry which contains the password, per pass</strong> conventions.</p>
</a></p>
Using in Emacs Configuration</h2>
For single secrets, like connecting to my znc</strong> IRC bouncer:</p>
(erc-tls :id 'znc :server "********"
</span>         :port "****" :user "xyz" :nick
</span>         "foobar" :password (auth-source-pass-get 'secret "foobar/znc")))
</span></code></pre>
For multifield secrets, like for google authentication, we can
leverage the multiple fields in the password store. Here is my
org-gcal</strong> configuration:</p>
(setq org-gcal-client-id (auth-source-pass-get 'secret "snamellit/org-gcal-client")
</span>      org-gcal-client-secret (auth-source-pass-get "id" "snamellit/org-gcal-client")
</span>      org-gcal-fetch-file-alist '(("xyz@foobar.com" .  "~/org/schedule.org")))
</span></code></pre>
</a></p>
Shell integration</h1>
</a></p>
DirEnv integration</h2>
When developping 12-factor or similar inspired apps, the configuration
is passed using environment variables. Using .envrc</strong> files with
direnv</strong> integration in the shell is a very smooth way to work in
multiple projects.</p>
It is of course less than ideal to have the secrets exposed in the
.envrc</strong> files in your project tree even if it is in the .gitignore</strong>
file, although that is infinitely better than having secrets end up in
the git repository.</p>
Secrets in the .envrc</strong> files can be easily moved to the password store
by entering the folder. The following snippet prints the current value
to the screen and then inserts it in the password store, and verifies
it actually is entered correctly.</p>
$ echo $FOO_BAR_PASSWORD
</span>$ echo $FOO_BAR_PASSWORD | pass add -e foo/bar
</span>$ pass foo/bar
</span></code></pre>
and then editing the .envrc</strong> file from</p>
...
</span>FOO_BAR_PASSWORD=<some secret>
</span>...
</span></code></pre>
to</p>
...
</span>FOO_BAR_PASSWORD=$(pass foo/bar)
</span>...
</span></code></pre>
After modification you'll be asked to allow to read the new .envrc</strong>
file content and you can check if it still works by comparing the
password with the one printed previously.</p>
Printing the passwords allows to fix any typos. If this are the only
copies you have of them you might rug-pull yourself. Ideally it should
be possible to quickly recreate secrets if you lose any, but reality
is often far from ideal. Echoing all these passwords is also not
ideal, but preferable over keeping a little black book of secrets. If
these passwords are coming from another password manager it is not
needed of course.</p>
Do not forget to clear your terminal scroll back history with</p>
$ clear
</span></code></pre>
To help migration of .envrc</strong> files I created a bash script I stored in
~/.local/bin/envrc-to-pass</strong>:</p>
#!/bin/bash
</span>
</span>if [ "$#" -ne 2 ]; then
</span>    echo "Usage: $0 <variable_name> <namespace>" >&2
</span>    exit 1
</span>fi
</span>
</span>VAR_NAME=$1
</span>SLUG=$(echo $VAR_NAME | sed 's/_/-/g' | tr '[:upper:]' '[:lower:]')
</span>NAMESPACE=$2
</span>
</span>
</span>echo "Moving variable $VAR_NAME to $NAMESPACE/$SLUG in password store"
</span>
</span>SECRET=$(grep "$VAR_NAME=" .envrc | cut -d'=' -f2)
</span>if (echo $SECRET | grep '^\$(pass.*)'); then
</span>    echo "secret already migrated"
</span>else
</span>    echo $SECRET | pass insert -e $NAMESPACE/$SLUG
</span>fi
</span>
</span>sed -i "s#$VAR_NAME=.*#$VAR_NAME=\\\$(pass $NAMESPACE\/$SLUG)#" .envrc
</span></code></pre>
This makes short work of migrating projects to use the password-store.</p>
</a></p>
Tips</h1>
</a></p>
Entering passwords on the terminal</h2>
Usually invoking `pass add foobar/baz` will ask to enter the password
and confirm it in the shell.</p>
However when piping a secret into the password-store
with</p>
echo FOO_BAR_PASSWORD | pass add foo/bar
</span></code></pre>
will silently fail although the man pages tell that `pass add` will
read from stdin</strong>. It is not clear IMO that you have to specify the -e</strong>
flag like :</p>
echo FOO_BAR_PASSWORD | pass -e add foo/bar
</span></code></pre>
to suppress the confirmation and make it work as expected.</p>
</a></p>
Getting fields from multi field secrets</h2>
Often secrets come in multiple parts which are nice to be stored in a
single entry in order not to complicate the tree. The pass</strong>
documentation suggests:</p>
<password or main secret>
</span>field1: <some data>
</span>field2: <more data>
</span></code></pre>
the main secret is just the first line, and can have the same
structure as the other lines, if that makes more sense.</p>
e.g. for a google integration:</p>
service-account: 1234567-abcdefghijklm@developer.gserviceadmin.com(some-project)
</span>email: xyz@foobar.com
</span>private-key: ...
</span></code></pre>
In this case it is useful to document</span> which kind of secret it is as it
could also be an api-key, or a refresh-token, or whatever part of the
authentication menagerie that Google offers.</p>
To get these fields individually I use:</p>
GOOGLE_EMAIL=$(pass foo/bar | awk '/^email:/ {print $2}) 
</span></code></pre>
in emacs this syntax is supported directly and the same info can be
fetched with</p>
(let
</span>    ((google-email (auth-source-pass-get "email" "foo/bar")))
</span>  ... )
</span></code></pre>


Terraform workflow using Guix and Emacs
Peter Tillemans — Wed, 05 Jun 2024 00:00:00 +0000
Terraform Deployments</h1>
Terraform allows infrastructure to be defined to deploy applications
and other solutions as code and supports a plethora of on-premise and
cloud deployment targets.</p>
It is essentially based on building a graph of dependencies between
resources, data and modules using the terraform language.</p>
Due to the nature of the beast these things tend to run in the CI
pipelines which makes editing these files frustrating as the edits
have to be committed, pushed, runners have to be scheduled and usually
the deploy pipeline is not the first job.</p>
So good local tooling is needed to get fast feedback.</p>
Terraform tooling on GUIX</h1>
In order to run terraform I need to first package it as it is not
available in the GUIX repositories.</p>
(define</span>-</span>public terraform
</span>  (package
</span>   (name </span>"snam-terraform"</span>)
</span>   (version </span>"1.8.4"</span>)
</span>   (source (origin
</span>            (method url</span>-</span>fetch)
</span>            (uri (</span>string</span>-</span>append </span>"https://releases.hashicorp.com/terraform/"</span> version </span>"/terraform_"</span> version </span>"_linux_amd64.zip"</span>))
</span>            (sha256
</span>             (base32
</span>	       </span>"1i181cmzwlrx8d40z1spilcwgnhkzwalrg8822d23sqdmrs7a5hj"</span>))))
</span>   (build</span>-</span>system binary</span>-</span>build</span>-</span>system)
</span>   (supported</span>-</span>systems '(</span>"x86_64-linux"</span>))
</span>   (arguments '(
</span>      #:install-plan
</span>      `((</span>"." </span>(</span>"terraform"</span>) </span>"bin/"</span>))
</span>      #:phases
</span>      (modify</span>-</span>phases %standard</span>-</span>phases
</span>		     </span>;; this is required because standard unpack expects
</span>		     </span>;; the archive to contain a directory with everything inside it,
</span>		     </span>;; while babashka's release .tar.gz only contains the `bb` binary.
</span>		     (</span>replace</span> 'unpack
</span>			      (</span>lambda</span>* </span>(#:key inputs #:allow-other-keys)
</span>				(system</span>* </span>(which </span>"unzip"</span>)
</span>					 (</span>assoc</span>-</span>ref inputs </span>"source"</span>))
</span>				#t)))))
</span>   (inputs
</span>    `((</span>"libstdc++"</span> ,(make</span>-</span>libstdc</span>++</span> gcc))
</span>      (</span>"zlib"</span> ,zlib)))
</span>   (native</span>-</span>inputs
</span>    `((</span>"unzip"</span> ,unzip)))
</span>   (synopsis </span>"A tool to describe and deploy infrastructure as code"</span>)
</span>   (description
</span>    </span>"Terraform allows you to describe your complete infrastructure in the form of code. Even if your servers come from different providers such as AWS or Azure, Terraform helps you build and manage these resources in parallel across providers."</span>)
</span>   (home</span>-</span>page </span>"https://hashicorp.com/terraform"</span>)
</span>   (license #f)))
</span>
</span>(define</span>-</span>public snam</span>-</span>terraform</span>-</span>1.6
</span>  (package
</span>    (inherit terraform)
</span>    (version </span>"1.6.6"</span>)
</span>    (source (origin
</span>             (method url</span>-</span>fetch)
</span>             (uri (</span>string</span>-</span>append </span>"https://releases.hashicorp.com/terraform/"</span> version </span>"/terraform_"</span> version </span>"_linux_amd64.zip"</span>))
</span>             (sha256
</span>              (base32
</span>	       </span>"002g0ypkkfqy5nf989jyk3m1l7l0455hsaq11xfhr5lbv4zqh5yi"</span>))))))
</span>
</span></code></pre>
I immediately added support to build older versions because that's
what the customer is on and terraform is quite version dependent
AFAICT.</p>
Now I can create a manifest for this project. I usually bootstrap them
with guile shell --export-manifes go gopls</code> or similar and then add
stuff when it comes up.</p>
;; What follows is a "manifest" equivalent to the command line you gave.
</span>;; You can store it in a file that you may then pass to any 'guix' command
</span>;; that accepts a '--manifest' (or '-m') option.
</span>
</span>(specifications</span>-></span>manifest
</span>  (</span>list </span>"go" "gopls" 
</span>        </span>"google-cloud-sdk" 
</span>        </span>"postgresql" 
</span>        </span>"snam-terraform-1.6" </span>; from snamellit channel
</span>        ))
</span></code></pre>
Direnv support</h1>
In order to manage my project environment and align it with the CI
environment I added the expected variables and use the guix support in
the stdlib of direnv. This will create a guix environment configured
from the manifest.</p>
use guix
</span>
</span>export DB_URL="postgresql://<db_ip>/myproj"
</span>export DB_USER="xyz"
</span>export DB_PASSWORD="secret"
</span>export PGPASSWORD=$DB_PASSWORD
</span>
</span>export VAULT_TOKEN="<blablabla>"
</span>export APPTIO_URL=https://acme.tpondemand.com
</span>export APPTIO_TOKEN=<blablabla>
</span>
</span>export OPENAI_API_KEY=<blablabla>
</span>
</span>export VAULT_ADDR=https://vault.acme.com
</span>export STATE_BUCKET=com-acme-test-myproj-tf-state
</span>
</span>export TF_VAR_project_short=myproj
</span>export TF_VAR_project=com-acme-test-${TF_VAR_project_short}
</span>
</span>PATH_add ./node_modules/.bin
</span></code></pre>
Emacs support</h1>
Direnv Support</h2>
Emacs direnv mode</em> will load the configuration from the .envrc</em> file
when opening a file in that project. The variables and apps are then
available for complition, LSP, shell, etc.</p>
;; enable direnv mode
</span>(direnv</span>-</span>mode)
</span></code></pre>
I just enable it globally because I want that always, not just for
terraform.</p>
Terraform Support</h2>
Enable some syntax highlighting and more importantly documentation
help. Also set format-on-save</code> and the indent to 2 spaces</p>
;; configure terraform support
</span>(</span>require</span> 'terraform</span>-</span>mode)
</span>(add</span>-</span>hook 'terraform</span>-</span>mode</span>-</span>hook 
</span>          (</span>lambda </span>()
</span>            (outline</span>-</span>minor</span>-</span>mode </span>1</span>)))
</span>(custom</span>-</span>set</span>-</span>variables
</span> '(terraform</span>-</span>indent</span>-</span>level </span>2</span>)
</span> '(terraform</span>-</span>format</span>-</span>on</span>-</span>save </span>t</span>))
</span></code></pre>
and expose the functionality in similar keybindings as I use for LSP
support :</p>
(evil-define-key 'normal terraform-mode-map
</span>  (kbd "<leader>c k") #'terraform-open-doc
</span>  (kbd "<leader>c f") #'terraform-format
</span>  (kbd "<leader>c F") #'terraform-format-buffer
</span>  (kbd "<leader>c n") 'flymake-goto-next-error
</span>  (kbd "<leader>c p") 'flymake-goto-prev-error)
</span></code></pre>
</em> will now open a browser window with the documentation of
the terraform element under the cursor. This does need terraform to be
installed though.</p>
Add support to Makefile</h2>
In order to save me from remembering the commandlines and because I
keep the terraform files in a terraform</em> directory I make some make</em>
targets to quickly access them.</p>

</span>tfinit</span>: 
</span>	</span>terraform</span> -chdir</span>=</span>terraform init -backend-config</span>=</span>"bucket=</span>${</span>STATE_BUCKET</span>}</span>"
</span>
</span>tfcheck</span>:
</span>	</span>terraform</span> -chdir</span>=</span>terraform validate
</span>
</span>tfapply</span>:
</span>	</span>terraform</span> -chdir</span>=</span>terraform apply
</span>
</span>tfplan</span>:
</span>	</span>terraform</span> -chdir</span>=</span>terraform plan
</span>
</span>tflint</span>:
</span>	</span>docker</span> run --rm -v `</span>pwd</span>`/terraform:/data -t ghcr.io/terraform-linters/tflint
</span>
</span></code></pre>
Workflow tips</h1>
Most of it is essentially hidden in the normal workflow. i.e. opening
a terraform file will load it, saving formats it. The compile</em> feature
can be used to do file checking and linting.</p>
Magit commit - push triggers the CI pipeline to run the deploy.</p>
It is easy to test things out locally with the Makefile and it reduces
the number of steps in the CI script , so less things which can do
weird things.</p>

Snamellit - guix

Install GUIX on Macbook 12

Post Installation</h2>

Sound : no sound from speakers.</h3> There is no sound coming from the speakers.</p> There is sound coming from the headphone jack. Good enough for use in the living.</p> I'll call this a feature, not a bug.</p>

Things I would do differently</h2> Basically use btrfs to have a single encrypted LUKS volume to deal with and split the volumes in btrfs. That would also give the other goodness of btrfs and should be well supported by grub.</p> But for now I'll enjoy my new couch laptop.</p>

Screenshot in Sway with GUIX

Samba Adventures with Guix

Workflows for Unix Password Store with Emacs and Shell

Terraform workflow using Guix and Emacs

Emacs support</h1>

Sound : no sound from speakers.</h3>
There is no sound coming from the speakers.</p>
There is sound coming from the headphone jack. Good enough for use in the living.</p>
I'll call this a feature, not a bug.</p>

Things I would do differently</h2>
Basically use btrfs to have a single encrypted LUKS volume to deal with and split the volumes in btrfs. That would also give the other goodness of btrfs and should be well supported by grub.</p>
But for now I'll enjoy my new couch laptop.</p>