Progress on 'guix deploy'
Hello, Guix! Apart from a few patches and my introductory email about a month ago, I've been pretty silent. I feel it's time to finally break that silence, let people know where progress has been made, and request some feedback on the code I've written so far. As a quick refresher, my GSoC project this summer is 'guix deploy', a deployment automation tool for GuixSD that's been discussed more thoroughly in [1] and [2]. Development has taken place on my personal branch of Guix, specifically the 'wip-deploy' branch [3], and is represented by three new Scheme source files: - 'gnu/machine.scm', which provides an abstraction for /something/ that can be deployed to in a heterogeneous deployment. Currently, the only concrete implementation of this is the simple case of in-place updates to machines running SSH whose names and IP addresses we know. - 'gnu/tests/machine.scm', which implements some tests for 'gnu/machine.scm'. This is where I'm most interested in receiving feedback. More on that later. - 'guix/scripts/deploy.scm', which implements the rudimentary command-line interface for 'guix deploy'. The command-line interface hasn't really been fleshed out yet, but if you'd like to play around with it, it takes a "deployment" file as a parameter, which is a Scheme file looking something like the following: #+BEGIN_SRC scheme (use-modules ...) (define %system (operating-system (host-name "gnu-deployed") (timezone "Etc/UTC") (bootloader (bootloader-configuration (bootloader grub-bootloader) (target "/dev/sda") (terminal-outputs '(console (file-systems (cons (file-system (mount-point "/") (device "/dev/vda1") (type "ext4")) %base-file-systems)) (services (append (list (service dhcp-client-service-type) (service openssh-service-type (openssh-configuration (permit-root-login #t) (allow-empty-passwords? #t %base-services (list (make #:host-name "localhost" #:ssh-port 5556 #:system %system)) #+END_SRC Basically, you attach an 'operating-system' declaration to a 'machine'. In this case, 'sshable-machine' is the specific type of 'machine' that we're deploying to (one that's running an SSH daemon and has a known IP + port + hostname). I've found that the GuixSD QEMU images work well for playing around with this, provided that you add the SSH service to the system configuration and start it. In the case of this deployment file, I had a GuixSD guest with port 22 forwarded to my host's port 5556. You'll also need to set up some sort of public key auth in your SSH config. The current code isn't capable of handling other forms of SSH authentication. In terms of implementation, GOOPS feels like a bit of an unusual choice when juxtaposed with the rest of the Guix codebase, but I've come to really enjoy it. I'll roll with it for now, since I think it will make it easier to flesh out the vocabulary for specifying deployments. The implementation of '' is doing what 'switch-to-system' and 'install-bootloader' in 'guix/scripts/system.scm' do, but in terms of data that can be sent with 'remote-eval'. I imagine the code will make more sense if you read both simultaneously. Okay, on to the test suite. My understanding of the system test suite (tests run with 'check-system' as opposed to those run with 'check') is that the meat of the test code exists in a G-Expression and should _not_ be interacting with the store of the machine running the test suite (i.e. that's the reason we're using marionettes in the first place). 'gnu/tests/install.scm' seems to be somewhat of an exception, and because the code in '(gnu machine)' depends heavily on having access to a store, I've tried to extend what's done in 'gnu/tests/install.scm' so that my tests have access to store while instrumenting the marionettes. To be specific, the chicken and egg scenario I'm working around is that the SSH daemon on the marionette needs to be running in order for 'deploy-os' to work, but I can't call 'deploy-os' from the test G-Expression because the store wouldn't be accessible then. My gut is telling me that this is absolutely the wrong way to go about it, though. 'call-with-marionette' is one of a couple red flags making me feel that way -- I don't think marionettes were meant to be started outside the context of a derivation... If anyone has suggestions on how I might go about properly testing this code, I would appreciate it very much. Another point about the test suite: the 'ssh-deploy-os' test fails, but it's a reproducible version of the issue outlined in [2]. I'd like to conscript some help from those more familiar with guile-ssh before breaking out the ol' RFCs myself. ... So, if anyone's in the mood to peek at what's
Re: SELinux log
--8<---cut here---start->8---
type=FS_RELABEL msg=audit(1559947443.686:26389): pid=2658 uid=0 auid=1000
ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
msg='op=mass relabel exe="/usr/sbin/setfiles"
hostname=localhost.localdomain addr=? terminal=pts/1 res=failed'UID="root"
AUID="laura"
type=MAC_POLICY_LOAD msg=audit(1559947618.423:26390): auid=1000 ses=3
lsm=selinux res=1AUID="laura"
type=USER_AVC msg=audit(1559947745.466:39283): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: received
policyload notice (seqno=3) exe="/usr/lib/systemd/systemd" sauid=0
hostname=? addr=? terminal=?'UID="root" AUID="unset" SAUID="root"
type=USER_AVC msg=audit(1559947745.467:39284): pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: received
policyload notice (seqno=4) exe="/usr/lib/systemd/systemd" sauid=0
hostname=? addr=? terminal=?'UID="root" AUID="unset" SAUID="root"
type=AVC msg=audit(1559947746.785:39285): avc: denied { relabelto } for
pid=2688 comm="restorecon" name="guix" dev="dm-0" ino=311508
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:guix_daemon.guix_daemon_conf_t:s0 tclass=dir
permissive=0
type=AVC msg=audit(1559947746.787:39286): avc: denied { relabelto } for
pid=2688 comm="restorecon" name="acl" dev="dm-0" ino=306189
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:guix_daemon.guix_daemon_conf_t:s0
tclass=file permissive=0
--8<---cut here---end--->8---
Re: SELinux log
Sorry, my mail client apparently hates me, it is somewhat formatting my mails after sending them ¬¬
Re: SELinux log
Hi!
> Thank you, the log is helpful (even though it looks like your mail
> client reformatted it, which makes it very hard to read).
Sorry for that :/
> Did you run “restorecon” on the store to recursively label all files?
I did, but I have just found that you are right, looking at the log
that it is not labeling properly (I am running the commands like they
are in the manual, with the proper path to the policy, and `restorecon
-r /`), weird, see:
--8<---cut here---start->8---
type=FS_RELABEL msg=audit(1559947443.686:26389): pid=2658 uid=0
auid=1000 ses=3
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
msg='op=mass relabel exe="/usr/sbin/setfiles"
hostname=localhost.localdomain addr=? terminal=pts/1
res=failed'UID="root" AUID="laura"
type=MAC_POLICY_LOAD msg=audit(1559947618.423:26390): auid=1000 ses=3
lsm=selinux res=1AUID="laura"
addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus"
type=USER_AVC msg=audit(1559947745.466:39283): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='avc: received policyload notice (seqno=3)
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=?
terminal=?'UID="root" AUID="unset" SAUID="root"
type=USER_AVC msg=audit(1559947745.467:39284): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='avc: received policyload notice (seqno=4)
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=?
terminal=?'UID="root" AUID="unset" SAUID="root"
type=AVC msg=audit(1559947746.785:39285): avc: denied { relabelto }
for pid=2688 comm="restorecon" name="guix" dev="dm-0" ino=311508
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:guix_daemon.guix_daemon_conf_t:s0
tclass=dir permissive=0
type=AVC msg=audit(1559947746.787:39286): avc: denied { relabelto }
for pid=2688 comm="restorecon" name="acl" dev="dm-0" ino=306189
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:guix_daemon.guix_daemon_conf_t:s0
tclass=file permissive=0
--8<---cut here---end--->8---
And taking a look at /gnu I get:
d?? ? ???? gnu
:S
Regards :)
Laura
Re: [ANNOUNCE] ganeti-instance-guix 0.3
Hi Marius, Marius Bakke skribis: > I am happy to announce a new version of 'instance-guix', a Ganeti OS > provider that creates Guix systems. It is a <100 line shell script. Congrats! > Guix is a functional package manager that can be installed on any > GNU/Linux distribution, and offers a declarative operating system > interface. Ganeti is an API-driven clustered virtual machine manager > with strong consistency guarantees. Together they form a very powerful > abstraction for building infrastructure with code. I think you should write a blog article about the use cases and how this fits together, for someone not familiar with Ganeti (like me!) or with Guix. Thanks, Ludo’.
Re: Lightning talk at IPFS camp
Konrad Hinsen skribis: > Ludovic Courtès writes: > >> (They could have chosen Guile instead of a custom Lisp, but that’s an >> “implementation detail”. :-)) > > From my reading of the whitepaper, no. They have pretty strict > constraints on their language because they send live code updates > to running instances and want to be able to make certain guarantees. > Guile, or any other Scheme, would be too flexible. Oh right, I had overlooked that aspect of the project. Interesting! Ludo’.
Re: New SLiM theme.
Hello! Diego Nicola Barbato skribis: > From bfa773e0907ebe4f89bb5614a09d23d3e692d8d5 Mon Sep 17 00:00:00 2001 > From: Diego Nicola Barbato > Date: Mon, 3 Jun 2019 16:21:25 +0200 > Subject: [PATCH v2] slim: Add 1.x theme. Pushed! Thanks for fixing this omission! :-) You’re welcome to update (gnu artwork) now. Ludo’.
Re: Lightning talk at IPFS camp
Ludovic Courtès writes: > (They could have chosen Guile instead of a custom Lisp, but that’s an > “implementation detail”. :-)) >From my reading of the whitepaper, no. They have pretty strict constraints on their language because they send live code updates to running instances and want to be able to make certain guarantees. Guile, or any other Scheme, would be too flexible. Konrad.
Re: Lightning talk at IPFS camp
Ludovic Courtès writes: > Hey! > > I stumbled upon this: > > https://github.com/ipfs/package-managers#readme And I just stumbled on this one: https://github.com/ipfs/roadmap Quote: 2019 Priority We will be focusing our efforts into a single (lazer focus) priority. Package Managers This looks like just the right moment to tell them about the one true package manager ;-) Konrad.
Re: Lightning talk at IPFS camp
Hi! Pierre Neidhardt skribis: > Konrad Hinsen writes: [...] >> For human input, Git would be OK, with repositories stored in IPFS >> (there's already some support for that, see >> https://github.com/ipfs/go-ipld-git). A more radical redesign is >> Radicle (http://www.radicle.xyz/), which uses IPFS as a collaboration >> platform (still at the git level). I guess Radicle could be used for >> much more than that in Guix, but I haven't looked at that in detail. > > Didn't know Radicle, it looks fantabulous! And... it uses (or plans to) > a Scheme-based language! :) It looks like the “right” design, or at least one that I find super interesting! (They could have chosen Guile instead of a custom Lisp, but that’s an “implementation detail”. :-)) Ludo’.
Re: Lightning talk at IPFS camp
Hey! I stumbled upon this: https://github.com/ipfs/package-managers#readme Hopefully that’s something you’ll discuss at IPFS Camp! Ludo’.
Reviewing KDE Plasma state on Guix System
Hi Guix, First, I would like to congratulate and thank you for the excellent work you are doing in the development of both Guix and this community. Then, I'm writing today because I would be interested to have the KDE Plasma desktop running on Guix System. I am willing to participate in its integration; I have already seen —roughly— that a good part of kde-frameworks was already packaged in the Guix depots; I also saw that some core parts for the desktop are currently missing. Before I start a full diagnosis of the current situation, I would like to know: does someone in the team already have done so? or would perhaps be responsible for integrating the KDE packages? in short, have we now a good overview of the current situation, on where the KDE packaging process is currently at? If there isn't any "global vision" of the state-of-the-art for the Plasma desktop yet, I would be happy to take care of it, by searching on the mailing list, testing the different parts already integrated, the necessary dependencies, the missing parts, etc. I'm a newby in Guile and Guix, so it would probably take time (and questions) Thanks and happy hacking, -- Félicien Pillot 2C7C ACC0 FBDB ADBA E7BC 50D9 043C D143 6C87 9372 felic...@gnu.org - felicien.pil...@riseup.net pgpzmhiNwJW7X.pgp Description: Signature digitale OpenPGP
