Guix with Debian GNU/Linux

Guix with Debian GNU/Linux

[Ni*]

I will soon setup a number of new servers with Debian GNU/Linux.
I decided to run them with GNU/Guix for packages and strip down
the image I get installed as much as possible.
So I have some questions for using Debian Jessie with GNU/Guix:

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?

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)

What are things I should look for and be careful about? What can be
removed from the hostsystem, what needs to stay?
Are guix updates handled the same way as they are done in GuixSD
(guix pull ; guix package -u)?

I will the manual before I setup the systems, but I thought asking some
questions before would be better. I am sure some of the questions I have
are answered in the manual.

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

Re: Guix with Debian GNU/Linux

[Ludovic Courtès]

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.

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

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

Thanks,
Ludo’.

Re: Guix with Debian GNU/Linux

[Ni*]

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?
>> 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,

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

Re: Guix with Debian GNU/Linux

[Leo Famulari]

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

Re: Guix with Debian GNU/Linux

[Ni*]

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.

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.
[Unit]
Description=Build daemon for GNU Guix
[Service]
ExecStart=/gnu/store/632msbms2yaldfnlrb5lbnlnmn9yjisw-guix-0.9.0/bin/guix-daemon --build-users-group=guixbuild
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.



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

Re: Guix with Debian GNU/Linux

[Leo Famulari]

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)