[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix with Debian GNU/Linux

From: Ni*
Subject: Re: Guix with Debian GNU/Linux
Date: Sat, 02 Jan 2016 01:10:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Leo Famulari <address@hidden> writes:

> On Wed, Dec 30, 2015 at 11:21:55PM +0100, Ni* wrote:
>> address@hidden (Ludovic Courtès) writes:
>> > Ni* <address@hidden> 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 
>> > <>.
>> >
>> > 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 and
>> 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 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 from here.
>> > Thanks,
>> > Ludo’.
>> 1: Individual Network Berlin e.V.
>> Thanks,

I get the feeling running GuixSD would be easier.

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?

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)?
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.

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.
Description=Build daemon for GNU Guix

trying to get OpenNTPD to work:
cat /etc/systemd/system/openntpd.service 
Description=OpenNTP Daemon
ExecStart=/root/.guix-profile/sbin/ntpd -s -d -f 

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 
 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.

Email is public. Talk to me in private:
privacy respecting, secure communication:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]