[Nix-commits] [NixOS/nixpkgs] e362a3: nginx: Format the config file

2017-02-07 Thread Svein Ove Aas
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e362a3d5c94ba379d428fbd2cc40470719a61556
  
https://github.com/NixOS/nixpkgs/commit/e362a3d5c94ba379d428fbd2cc40470719a61556
  Author: Svein Ove Aas <sve...@gmail.com>
  Date:   2017-02-07 (Tue, 07 Feb 2017)

  Changed paths:
M nixos/modules/services/web-servers/nginx/default.nix

  Log Message:
  ---
  nginx: Format the config file


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] 3d7897: nginx-config-formatter: init at 2016-06-16 (#22179...

2017-01-27 Thread Svein Ove Aas
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 3d78976c58492a0455c98f531eb3782206529c1d
  
https://github.com/NixOS/nixpkgs/commit/3d78976c58492a0455c98f531eb3782206529c1d
  Author: Svein Ove Aas <svein@aas.no>
  Date:   2017-01-27 (Fri, 27 Jan 2017)

  Changed paths:
A pkgs/tools/misc/nginx-config-formatter/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  nginx-config-formatter: init at 2016-06-16 (#22179)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] fec95a: ddclient: Don't include blank server= lines.

2017-01-16 Thread Svein Ove Aas
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: fec95a40f1d4eba786f8404b4dcc5dc1de15393f
  
https://github.com/NixOS/nixpkgs/commit/fec95a40f1d4eba786f8404b4dcc5dc1de15393f
  Author: Svein Ove Aas <sve...@gmail.com>
  Date:   2017-01-16 (Mon, 16 Jan 2017)

  Changed paths:
M nixos/modules/services/networking/ddclient.nix

  Log Message:
  ---
  ddclient: Don't include blank server= lines.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] 54fdd0: java program: Init.

2016-10-01 Thread Svein Ove Aas
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 54fdd0cf9c588e681ed0bad3eceee8e02f31d900
  
https://github.com/NixOS/nixpkgs/commit/54fdd0cf9c588e681ed0bad3eceee8e02f31d900
  Author: Svein Ove Aas <sve...@gmail.com>
  Date:   2016-10-01 (Sat, 01 Oct 2016)

  Changed paths:
M nixos/modules/module-list.nix
A nixos/modules/programs/java.nix

  Log Message:
  ---
  java program: Init.

Mostly just provides a shell hook for the jdk's setup-hook.
Tested with openjdk and jre.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] cbe883: factorio: Fix the fetch script (#17741)

2016-08-14 Thread Svein Ove Aas
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: cbe8832cd7ad4c57eec43e0a66b782004bafa4ee
  
https://github.com/NixOS/nixpkgs/commit/cbe8832cd7ad4c57eec43e0a66b782004bafa4ee
  Author: Svein Ove Aas <svein@aas.no>
  Date:   2016-08-14 (Sun, 14 Aug 2016)

  Changed paths:
M pkgs/games/factorio/fetch.nix
M pkgs/games/factorio/fetch.sh

  Log Message:
  ---
  factorio: Fix the fetch script (#17741)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] 9a8e0d: zfs: Force sync on shutdown (#16903)

2016-07-19 Thread Svein Ove Aas
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 9a8e0d1c2ef11a2ae0b7b5669ff28059db1dde4f
  
https://github.com/NixOS/nixpkgs/commit/9a8e0d1c2ef11a2ae0b7b5669ff28059db1dde4f
  Author: Svein Ove Aas <svein@aas.no>
  Date:   2016-07-19 (Tue, 19 Jul 2016)

  Changed paths:
M nixos/modules/tasks/filesystems/zfs.nix

  Log Message:
  ---
  zfs: Force sync on shutdown (#16903)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


Re: [Nix-dev] Monitoring by default

2016-04-22 Thread Svein Ove Aas
Thanks for the responses so far!

Let me see...

- I actually agree with Tomas about naming. I know I wrote
"services.monitoring.enable", but I hadn't put a lot of thought into that
sentence; "services.monitoring.prometheus" seems like a better namespace.

- I'd add battery life to the list of things we collect, but I don't have a
laptop to run NixOS on at present, and the "over the years" part of that
suggestion doesn't fit well with Prometheus, which runs up against
Prometheus being the only monitoring system I really know. Still, if I
write the monitoring console right, it should be possible to include other
services.

- I think "Generate instructions for enabling it in configuration.nix" is
the consensus so far. Let's do that. One question might be what to do about
already-installed systems, but I suppose I can write a blog post once this
is ready for use.

- I didn't know about systemd-cgtop. Neat.

- I'll try to keep pointless metric collection to a minimum, but some of
them aren't pointless. E.g. GPU memory use; there's really no call for
alerting based on that, ever, but it'd still be useful for informing
purchase decisions. (They tend to swap into main memory, which won't
register.)

The problem with turning on collection only once you have a problem, is
that it may turn out you really needed the data from ten hours ago; e.g.
imagine seeing a graph where disk usage takes a sharp spike after the
latest system upgrade. That's trivial for humans to spot, but moderately
difficult for computers. (And it won't happen if we don't collect.)

The data isn't going to make its way off the computer. My main concern is
memory usage... for the moment, I'm aiming for a ballpark figure of 100MB
for the service overall. Of course, it can write metrics out to disk; say
1GB there. Those will be configurable, but there's only so much you can cut
before alerts stop working.

- For "System software too old", what I'm really aiming at is an alert
saying "Hey, you haven't upgraded your system in half a year, and there's
probably some security flaws in there by now." The details are TBD; since
we don't have people watching all the security lists and keeping Nix up to
date, using age-of-installed-channel as a proxy is probably the best we can
do.

A lot of the things I'd like to alert on, on my own system, would be mildly
questionable on others. I'll try to include config options where it makes
sense to me, but... this sort of detailed discussion is really for the PRs.

- And I don't suppose I can deny being at Google, no, but this isn't a
Google project; I've just ended up using NixOS *everywhere* in my personal
life, so now I want monitoring. ;-)

On Thu, Apr 21, 2016 at 9:41 PM Layus <layus...@gmail.com> wrote:

> I like the idea too.
>
> It seems to me that distributions really lack metrics collection and
> data analysis.
> For example, it would be nice to have automatic gathering of the battery
> usage (charge/discharge/capacity) and an easy access to compiled
> historical data like the capacity loss over the years.
>
> I know this is far less ambitious than what you describe, but it would
> be a great entry point for new users.
> If they like it, they may want to gather wore statistics.
>
> Anyway, I think it makes total sense to have such a feature in NixOS.
>
> -- Layus.
>
> On 20/04/16 11:49, Rok Garbas wrote:
> > +1 for the initiative. i don't believe personally enabling monitoring
> > by default should be the right way to go (since we all use nixos in
> > different contexts), but having a commented instructions in generated
> > configurations.nix would be the way to go.
> >
> > it would be nice if systemd monitoring stuff could be used as well:
> > https://github.com/garbas/dotfiles/blob/master/nixos/rok.nix#L236
> > above line makes systemd-cgtop showing numbers.
> >
> >
> >
> > On Wed, Apr 20, 2016 at 8:44 AM, Alexei Robyn <sha...@shados.net> wrote:
> >> Seems interesting. You mention alerts for "System software too old.",
> but
> >> the only vaguely-universal definition of "too old" I can think of would
> be
> >> "missing security updates", and that's both debatable and an area where
> >> NixOS is currently fairly lacking in infrastructure and tooling.
> >>
> >> Default collection of metrics beyond what is necessary to provide useful
> >> alerts is a bad idea. Alerts have essentially universal usefulness,
> >> statistics less so - they're unnecessary for most desktops and small
> >> servers. At least until you have issues, so of course it'd be nice if
> they
> >> were easy to switch on :p.
> >>
> >> - Alexei
> >>
> >>
> >> On Wed, Apr 2

[Nix-dev] Monitoring by default

2016-04-19 Thread Svein Ove Aas
Hi all,

People who are not interested in reliability or monitoring can stop reading
now.

--

I've written up a "design doc" (statement of intent?) for how we might do
monitoring-by-default. Once I think there is a reasonable level of
consensus about how we should do this, I'll go ahead and implement what's
in the document, but I'd like to make sure we're all on the same page
first; especially as I want this to be *on* by default.

So I'd like your input. Can you take a look <https://goo.gl/wmsWpY>?

-- 
Svein Ove Aas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] JAVA_HOME and other environment variables

2016-03-06 Thread Svein Ove Aas
That's effectively what happens already, if you use nix-shell.

I'm concerned mostly about users who don't know to do that. Someone trying
to run a script from a different brand of unix, for example.

In theory, if there is a java binary on the PATH, there should also be a
JAVA_HOME. That's Oracle's take on this, but... well, I prefer Nix to have
as few surprises as possible.

On Sun, Mar 6, 2016 at 8:12 PM zimbatm <zimb...@zimbatm.com> wrote:

> What if the JRE(s) also included a `java-env.sh` that can be sourced ?
> Then it's easy to build wrappers that source it dynamically.
>
> On Sat, 5 Mar 2016 at 17:34 Svein Ove Aas <sve...@gmail.com> wrote:
>
>> Context: https://github.com/NixOS/nixpkgs/issues/13653
>>
>> There are a few packages which can't be considered properly installed
>> (and usable) without setting environment variables, this example being the
>> Java development kit.
>>
>> Some Java-based tools need to know where to find the JDK. The way they do
>> this is by looking at the JAVA_HOME environment variable. That is...
>> currently, it isn't set at all, unless you use nix-shell or an equivalent
>> mechanism.
>>
>> I've thought of a couple of solutions, but would welcome other
>> suggestions. In no particular order...
>>
>> (The problem is not restricted to just JAVA_HOME.)
>>
>> - Wrapping the the JDK binaries with makeWrapper.
>>   This is a non-starter, as it's common to use JAVA_HOME in scripts.
>>
>> - JAVA_HOME is set in the JDK's setup-hook. We can source that file on
>> shell startup.
>>   This works well for nix-shell, and is the approach I've chosen to take
>> globally for a temporary fix. Unfortunately, it is in a sense even worse
>> than the status quo. Since this produces a pointer into /nix/store, the
>> value of JAVA_HOME in a running shell can become invalid because the JDK in
>> question is GC'd (!), or superseded by a newer one *without* being deleted
>> (!!).
>>
>> - Adding another directory under /run, containing symlinks that we can
>> mutate.
>>   Has the obvious problem of impurity, but we're talking about system (or
>> user) profiles; they're already impure, in the same sense. I don't see any
>> technical issues here, but that doesn't mean there aren't any. I'm not sure
>> how to implement it, or even whether I should.
>>   We'd have "JAVA_HOME=/run/env/JAVA_HOME", or so.
>>
>> One further concern...
>>
>> - Right now, the only way to install Java system-wide is to put it in
>> environment.systemPackages. Or using nix-env. Either way, JAVA_HOME
>> wouldn't get set; this is true even with that PR. I've been trying to think
>> of ways to fix this, but I have no idea how. Send help!
>>   As a result, even if I add programs.java to NixOS, it doesn't help
>> anyone who's got the problem right now.
>>
>> 
>>
>> I'd like to implement a general solution for all such situations, ideally
>> one that would get merged. Rant over, though. Thoughts?
>>
> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] JAVA_HOME and other environment variables

2016-03-05 Thread Svein Ove Aas
Context: https://github.com/NixOS/nixpkgs/issues/13653

There are a few packages which can't be considered properly installed (and
usable) without setting environment variables, this example being the Java
development kit.

Some Java-based tools need to know where to find the JDK. The way they do
this is by looking at the JAVA_HOME environment variable. That is...
currently, it isn't set at all, unless you use nix-shell or an equivalent
mechanism.

I've thought of a couple of solutions, but would welcome other suggestions.
In no particular order...

(The problem is not restricted to just JAVA_HOME.)

- Wrapping the the JDK binaries with makeWrapper.
  This is a non-starter, as it's common to use JAVA_HOME in scripts.

- JAVA_HOME is set in the JDK's setup-hook. We can source that file on
shell startup.
  This works well for nix-shell, and is the approach I've chosen to take
globally for a temporary fix. Unfortunately, it is in a sense even worse
than the status quo. Since this produces a pointer into /nix/store, the
value of JAVA_HOME in a running shell can become invalid because the JDK in
question is GC'd (!), or superseded by a newer one *without* being deleted
(!!).

- Adding another directory under /run, containing symlinks that we can
mutate.
  Has the obvious problem of impurity, but we're talking about system (or
user) profiles; they're already impure, in the same sense. I don't see any
technical issues here, but that doesn't mean there aren't any. I'm not sure
how to implement it, or even whether I should.
  We'd have "JAVA_HOME=/run/env/JAVA_HOME", or so.

One further concern...

- Right now, the only way to install Java system-wide is to put it in
environment.systemPackages. Or using nix-env. Either way, JAVA_HOME
wouldn't get set; this is true even with that PR. I've been trying to think
of ways to fix this, but I have no idea how. Send help!
  As a result, even if I add programs.java to NixOS, it doesn't help anyone
who's got the problem right now.



I'd like to implement a general solution for all such situations, ideally
one that would get merged. Rant over, though. Thoughts?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev