Re: Guix with Debian GNU/Linux

[Leo Famulari <leo@famulari.name>]

On Sat, Jan 02, 2016 at 01:10:34AM +0100, Ni* wrote:
> Leo Famulari <leo@famulari.name> writes:
> 
> > On Wed, Dec 30, 2015 at 11:21:55PM +0100, Ni* wrote:
> >> ludo@gnu.org (Ludovic Courtès) writes:
> >> 
> >> > Ni* <niasterisk@grrlz.net> skribis:
> >> >
> >> >> From using GuixSD I know that as little files as possible should be
> >> >> created in /etc. When using Guix alone, is this still the recommended
> >> >> way of doing things?
> >> >
> >> > Most of the time, you can choose where to store config files, in /etc or
> >> > elsewhere.
> >> >
> >> >> What I need to know for a server environment is, if I install tor and
> >> >> serve non-exit tor relays, will the config be read from the location I
> >> >> am used to (/etc/tor/) or does it differ? (same about httpd/nginx, etc)
> >> >
> >> > Most programs allow you to choose which configuration file to use.  For
> >> > instance, one can run:
> >> >
> >> >   tor -f /path/to/torrc
> >> >
> >> > and Tor will pick its config file from there.  I think the same is true
> >> > of nginx and httpd.
> >> >
> >> I have to correct myself, as I confused tor configuration with
> >> GuixSD, where I have the impression it (tor) is configured in the
> >> system config.scm to some degree.
> >> Correction: debian to my knowledge (I don't have much in depth Debian
> >> experience, slackware forks, gentoo, archlinux, etc everything more used
> >> than Debian) runs with some /etc/init.d/* files + systemd combination.
> >> When I use Guix to just install packages, do I write
> >> systemd/debian-thing service/startup files, or am I confused by being
> >> exposed to Guix as GuixSD which runs dmd?
> >
> > Yes, you won't have dmd on the Debian system. And in Jessie, the init.d
> > files are really just holdovers from Wheezy that are interpreted by
> > systemd. I presume the maintainers of those packages did not submit
> > systemd service files.
> >
> >> >> What are things I should look for and be careful about? What can be
> >> >> removed from the hostsystem, what needs to stay?
> >> >
> >> > Compared to GuixSD, a couple of things need tweaking to work smoothly;
> >> > see <https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html>.
> >> >
> >> > As to what to keep in the host distro, it’s up to you!
> >> >
> >> > In some cases, you’ll have to make a binary choice; for instance, if you
> >> > use Guile from Guix, you’ll have to use Guile packages (say, Guile-SSH,
> >> > Guile-JSON, etc.) from Guix as well since otherwise they would end up
> >> > loading different variants of libguile.so and libc.so.
> >> Okay, this makes sense. Thanks for the pointers.
> >> >
> >> >> Are guix updates handled the same way as they are done in GuixSD
> >> >> (guix pull ; guix package -u)?
> >> >
> >> > Yes.
> >> >
> >> > Out of curiosity, what are the technical reasons that led you to prefer
> >> > Guix-over-Debian rather than GuixSD, since you tried GuixSD already?
> >> >
> >> Simple (but detailed) answer:
> >> I host with IN-Berlin[1] on virtual servers, they only provide Debian.
> >> If I could explain to them how to deploy it for servers (maybe images
> >> for the hardware they run the vservers on would already be enough),
> >> I would be able to run GuixSD. One thing I did though was telling and
> >> explaining one of people responsible for IN-Berlin what Guix and GuixSD
> >> is. Maybe it will be possible at some time in the future, they are very
> >> friendly.
> >> I would however prefer dedicated servers by now, but in the Ruhrarea
> >> (Region in Germany, NRW) the choice of ISPs, DCs and otherwise Hosters
> >> is so big that I always end up realizing that I can do better things
> >> with my time and leave it be. If I would be in Berlin regulary,
> >> maintenance would be no problem with colocation with IN-Berlin. Or
> >> hosting with free.de here, but I would say they don't like to answer questions
> >> about colocation contracts, at least that's my sad past experience with
> >> them, it would be a 10 minute ride to free.de from here.
> >> 
> >> > Thanks,
> >> > Ludo’.
> >> 
> >> 1: Individual Network Berlin e.V. http://in-berlin.de
> >> 
> >> Thanks,
> >>
> 
> I get the feeling running GuixSD would be easier.

It depends on your needs, but I find it very easy to run Guix on Debian
Stretch.

> 
> So far I managed to get guix running and to install packages and run
> them. However I don't know about systemd.
> 
> Long text below, what I wonder is what's the best way to define
> permanent .service files for guix?
> using ~/.guix-profile/ for ExecStart (which is just symlinks to the
> current versions) or some other directory structure outside root?

You can also use the paths under '/var/guix'. For example, I use this
path in the systemd service file that is used to manage the guix-daemon:
/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon

> 
> Additionally, if I change and add files in the /gnu/store/ of a package,
> like ntpd, will the changes and added files be available after I upgrade
> the package I added changes to the file(s)?

You should never change files in /gnu/store. It is read-only and the
directories in the store are expected to never change. The only thing
that writes to the store is the guix-daemon, and it always writes to a
new directory, AIUI. If you want to make a change to a package, you
should edit the package definition and rebuild the package.

> Or do I just use /etc/$upstreamdir for configurations and content?
> In the long run I will move everything to an GuixSD dedicated server,
> but right now I think I better ask.

That will work for configuration. "Content" should probably not go in
/etc if you are using Guix on a "foreign distro".

> 
> 
> 
> 
> 
> from the initial guix-daemon.service file after install:
> cat /etc/systemd/system/guix-daemon.service 
> # This is a "service unit file" for the systemd init system to launch
> # 'guix-daemon'.  Drop it in /etc/systemd/system or similar to have
> # 'guix-daemon' automatically started.
> [Unit]
> Description=Build daemon for GNU Guix
> [Service]
> ExecStart=/gnu/store/632msbms2yaldfnlrb5lbnlnmn9yjisw-guix-0.9.0/bin/guix-daemon --build-users-group=guixbuild

I would alter this path as mentioned above so that you don't have to
update the service file every time the daemon is upgraded. The store
directory only refers to a single version of the daemon. Otherwise, this
service file matches mine, which works well.

> RemainAfterExit=yes
> StandardOutput=syslog
> StandardError=syslog
> [Install]
> WantedBy=multi-user.target
> 
> trying to get OpenNTPD to work:
> cat /etc/systemd/system/openntpd.service 
> [Unit]
> Description=OpenNTP Daemon
> After=network.target
> Conflicts=systemd-timesyncd.service
> [Service]
> Type=simple
> #Type=forking
> ExecStart=/root/.guix-profile/sbin/ntpd -s -d -f /root/.guix-profile/etc/ntpd.conf
> Restart=on-failure
> [Install]
> WantedBy=multi-user.target
> 
> Where I had to create user "_ntp" to get it to work:
> useradd -M -s `which nologin` --system _ntp
> 
> which now gives me
> ● openntpd.service - OpenNTP Daemon
>    Loaded: loaded (/etc/systemd/system/openntpd.service; disabled)
>    Active: inactive (dead)
> 
>  ntpd[899]: Lost child: child exited
>  ntpd[899]: Terminating
>  ntpd[899]: dispatch_imsg in main: pipe closed
>  systemd[1]: Starting OpenNTP Daemon...
>  systemd[1]: Started OpenNTP Daemon.
>  ntpd[924]: adjtimex adjusted frequency by 0.000000ppm
>  ntpd[924]: fatal: privsep dir /home/_ntp could not be opened: No such file or directory
>  ntpd[924]: Lost child: child exited
>  ntpd[924]: Terminating
>  ntpd[924]: dispatch_imsg in main: pipe closed
> 
> which means I have the same problem I had when I created the user with:
> useradd -d /var/empty -s `which nologin` --system _ntp
> so I need to create an empty dir of some kind to make it work.

Here's a bit of info on the privsep dir:
https://github.com/openntpd-portable/openntpd-portable/issues/6

I don't really have any advice otherwise. I use Debian provided software
for these "system" services that need a lot of OS integration. Debian
does have an OpenNTPD package.

> 
> 
> 
> -- 
> ng/Ni*
> http://libertad.pw
> Email is public. Talk to me in private:
> https://psyced.org:34443/~niasterisk
> privacy respecting, secure communication:
> BM-2cSj8qEigE3CMaLU3CwPZf7T3LvzvnttsC
> (bitmessage)