Re: [Nix-dev] How do you manage bare-metal local servers with nixops

[zimbatm]

Rohit, try something like this:
https://gist.github.com/zimbatm/d466ef56f88605f78f99

On Mon, 14 Dec 2015 at 22:47 Domen Kožar  wrote:

> You might want to test https://github.com/NixOS/nixpkgs/pull/11279
>
> On Mon, Dec 14, 2015 at 10:45 PM, rohit yadav 
> wrote:
>
>> Hi Zimbatm,
>>
>> I have very similar arrangement. I use git and to keep the configuration
>> synced. However, I wish to use NixOps, I haven't been able to find time to
>> do that. From the documentation I could not figure out how to deploy on
>> bare-metal. But as Christoph mentioned that a simple Ip-Address in the
>> network is all you need with nixops do deploy. It will remove lot of boiler
>> plate configuration I have to write on each system.
>>
>> Thanks,
>> Rohit
>>
>> On Mon, Dec 14, 2015 at 3:33 PM, zimbatm  wrote:
>>
>>> Hi rohit,
>>>
>>> Personally I just have a folder per machine with the /etc/nixos folder
>>> and a little script that runs rsync + `nixos-rebuild --switch` on the
>>> target machine.
>>>
>>> Over time I will probably switch to using nixops as well but for a start
>>> it's working super well for me. Especially since it doesn't have any nix
>>> dependency on the source machine. It takes just a couple of seconds to
>>> deploy which is way better than anything I had in the past (ansible,
>>> puppet, capistrano, ...).
>>> On Thu, 10 Dec 2015 20:45 Christoph Hrdinka 
>>> wrote:
>>>
 Hi Rohit!

 You can use nixops to deploy to any server running ssh. All you have to
 do is install a basic NixOS system with opensshd enabled on your target
 server. Then tell nixops the hostname/ip address of the new server
 via `deployment.targetHost`.

 Nixops will evaluate any nix expression you give it. If you supply
 multiple files these will be merged. Your nix expression must yield an
 attribute set of the following form:

 {
   someMachineName =
 { config, lib, pkgs, ... }:
 {
   deployment.targetHost = "hostname or ip";
   # your usual nixos configuration file
   # ...
 }

   anotherMachine =
 {}
 }

 Every machine described in there will be deployed according to your
 configuation. Since it is a normal nix expression you can use any way
 to produce it. You can have basic templates that will be merged and
 overwritten by more specific ones, write everything in one file, spread
 it over hundret files or write a configuration syntax from which nix
 will derive all actual server configs.

 For what exactly do you need PXE? Is it for the initial NixOS install
 or do you want to use it because it worked for you till now with other
 systems?
 If you want it because of less configuration work it may be the wrong
 tool for a NixOS setup. Nixops is much better suited for this job than
 any PXE setup could ever be. It is made for simple deployment of
 hundrets of machines.

 You might also want to have a look at disnix/disnixos.

 Regards,
 Christoph Hrdinka.
 ___
 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 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] builder for ‘*.drv’ failed to produce output path ‘*’

[Tinker]

Thanks, that worked.

If I install it now and run `pgloader` I am getting (somewhere in sbcl):

Error opening shared object "libsqlite3.so.0":...

It works if I manually set the LD_LIBRARY_PATH

export LD_LIBRARY_PATH=
/nix/store/nn4srgg3f8hvb6x30df058kl67ar3wr9-lisp-cl+ssl-git-20141113/lib:/nix/store/w0ml3zjnqawcw2dlamn9q3pilplmgryi-openssl-1.0.1p/lib:/nix/store/z35b0yjmrhhl0cfxrkymf4387i3pjkjm-sqlite-3.8.11.1/lib:/nix/store/byk49dzimn7yxyjk16674yd54n6krwn3-freetds-0.91/lib

How do other utils typically deal with this?
Does the user need to do this himself after installing with nix-env?
And if so, how to find out the paths (I could find them out by opening
a nix-shell and inspecting the variable)?
Or is this something that should rather be done through a shell.nix or
an environment?

t

On Sun, Dec 13, 2015 at 11:46 PM, Tomasz Kontusz
 wrote:
> You need to create $out in your builder. Just "cp -r ./build $out" after
> the "make pgloader" will be a good start - at least you'll see if it's
> usable :-)
>
> On 13.12.2015 23:39, Tinker wrote:
>> Hi
>>
>> I'm trying to write a nix package for pgloader (a db migration tool
>> written by someone else and can be found at
>> https://github.com/dimitri/pgloader).
>>
>> When I run it as `nix-build -A pgloader` then I get:
>>
>> builder for ‘/nix/store/gz38vqm47i0vfyiqdz6qmqyx7ywprji5-pgloader-3.2.2.drv’
>> failed to produce output path
>> ‘/nix/store/v5ya763xia00lp40yx6z5c0h6l1cvla2-pgloader-3.2.2’
>> error: build of
>> ‘/nix/store/gz38vqm47i0vfyiqdz6qmqyx7ywprji5-pgloader-3.2.2.drv’
>> failed
>>
>> I'm trying to figure out what it means but maybe someone can already
>> shed a light?
>>
>> The package does not have a 'make install', is that why it's
>> complaining out the missing output path?
>> What would be the way forward given I don't own the source of the
>> utility itself?
>>
>> default.nix (other comments welcome as well):
>> ===
>> { stdenv, fetchurl, sbcl, unzip, curl, git, openssl, sqlite, freetds,
>> lispPackages, cacert }:
>>
>> stdenv.mkDerivation {
>>name = "pgloader-3.2.2";
>>buildInputs = [ sbcl unzip curl git openssl sqlite freetds
>> lispPackages.cl-ssl cacert ];
>>
>> LD_LIBRARY_PATH="${lispPackages.cl-ssl}/lib:${openssl}/lib:${sqlite}/lib:${freetds}/lib";
>>SSL_CERT_FILE=/etc/ssl/certs/ca-bundle.crt;
>>CURL_CA_BUNDLE=/etc/ssl/certs/ca-bundle.crt;
>>
>>builder = builtins.toFile "builder.sh" "
>>  source $stdenv/setup
>>
>>  PATH=$sbcl/bin:$PATH
>>
>>  unzip $src
>>  cd pgloader-*
>>  sed -i 's/COMPRESS_CORE ?= yes/COMPRESS_CORE ?= no/' Makefile
>>  make COMPRESS_CORE=no pgloader
>>";
>>
>>src = fetchurl {
>>  url = https://github.com/dimitri/pgloader/archive/master.zip;
>>  md5 = "8b93075a1a5848a674101d90850dc90e";
>>  #url = https://github.com/dimitri/pgloader/archive/v3.2.2.zip;
>>  #md5 = "4d00eb55bf7dbea0a8e55248d2bbb96d";
>>};
>>inherit sbcl;
>> }
>> ===
>>
>> t
>> ___
>> 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Which is the best way to reload all network configurations? (dhcpclient etc)

[Oliver Charles]

Does systemctl restart network.target work?

On Thu, Dec 10, 2015 at 10:21 AM Marco Maggesi 
wrote:

> Hi,
>
> I'm not confident with the systemd infrastructure.
>
> Which is the best way to shutdown/restart/reload the whole network
> infrastructure?
> (interfaces, dhcpclient, etc)?
>
> Thanks,
> Marco
> ___
> 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

Re: [Nix-dev] Regarding the unstable channel

[Eelco Dolstra]

Hi,

On 14/12/15 14:53, Eric Sagnes wrote:

> I am using the unstable channel and recently encoutered some issues to update 
> the system with `nixos-rebuild`, to list a few:
> 
> - flashplayer source not found (PR #11675)
> - udevil not building (PR #11702)
> - signing-party source not found (PR #11703)
> 
> All these issues have in common that the binary substitute was not available 
> and they were triggered during source building.
> As I understand it, a channel is updated when *all* the packages have been
> built and the binary cache is available [1].

Flash player is not built by Hydra at all, being proprietary.

Regarding the other packages, they're not release blockers, so if they fail to
build the channel will still be updated.

> I totally understand that issues are expected when using the something 
> labelled 
> unstable, but it might confuse some less technical users, or worse give a bad 
> impression to people that are trying NixOS.

It's like you said: for the unstable branch, this kind of breakage is
unavoidable and to be expected. Most users should therefore stick to the stable
branches.

> I am not familiar with hydra so I don't know what is possible to improve 
> the situation. 
> But for example, could it be possible to update the unstable channel when 
> none 
> or only a few jobs fail?

Sure, but then the unstable channel would *never* update :-) It's already hard
enough to get all the release-blocking builds/tests to succeed simultaneously.

> Also, I have no idea if it is technically possible, but having an automatic 
> weekly digest on the ML with some hydra evaluations statistics and a list of 
> "newly failing jobs" could be a way to bring attention on potential issues.

You can see all broken packages on the unstable branch here:

  http://hydra.nixos.org/jobset/nixos/trunk-combined

and the release blockers:

  http://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents

By contrast, the 15.09 branch:

  http://hydra.nixos.org/jobset/nixos/release-15.09

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] ZFS on TMP and dealing with missing mode mount option

[Roger Qiu]

Hi,

ZFS doesn't have a mode option during mounting. See: 
https://github.com/zfsonlinux/zfs/issues/4101

If I need a filesystem mounted with 1777 permissions and sticky bit on 
boot, how can do that with ZFS and the NixOS fileSystems settings?

The fileSystems settings has no option to run a post setup command like 
`chown 1777 /tmp`.

Thanks,
Roger

-- 
Founder of Matrix AI
http://matrix.ai/
+61420925975

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

Re: [Nix-dev] ZFS on TMP and dealing with missing mode mount option

[Alexander Zubkov]

The mode is not mount option, but permissions configured on filesystem's 
folder. You should mount needed filesystem to /tmp or somewhere else, do 
chown on that and then it will be written and saved on filesystem and 
should persist on remounting.

On 14.12.2015 16:31, Roger Qiu wrote:
> Hi,
>
> ZFS doesn't have a mode option during mounting. See:
> https://github.com/zfsonlinux/zfs/issues/4101
>
> If I need a filesystem mounted with 1777 permissions and sticky bit on
> boot, how can do that with ZFS and the NixOS fileSystems settings?
>
> The fileSystems settings has no option to run a post setup command like
> `chown 1777 /tmp`.
>
> Thanks,
> Roger
>

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

[Nix-dev] Regarding the unstable channel

[Eric Sagnes]

Hi,

I am using the unstable channel and recently encoutered some issues to update 
the system with `nixos-rebuild`, to list a few:

- flashplayer source not found (PR #11675)
- udevil not building (PR #11702)
- signing-party source not found (PR #11703)

All these issues have in common that the binary substitute was not available 
and they were triggered during source building.
As I understand it, a channel is updated when *all* the packages have been
built and the binary cache is available [1].

I totally understand that issues are expected when using the something labelled 
unstable, but it might confuse some less technical users, or worse give a bad 
impression to people that are trying NixOS.

This problem has no severe consequences as the system stays in a stable 
state, but it is a little unpleasing when trying to update the system with a
a local dev branch rebased on the current unstable and get update failures. 
(maybe this is more a development workflow problem?)

I am not familiar with hydra so I don't know what is possible to improve 
the situation. 
But for example, could it be possible to update the unstable channel when none 
or only a few jobs fail?
Also, I have no idea if it is technically possible, but having an automatic 
weekly digest on the ML with some hydra evaluations statistics and a list of 
"newly failing jobs" could be a way to bring attention on potential issues.

Cheers,
Eric

[1] http://nixos.org/nixos/manual/index.html#sec-upgrading
-- 
Eric Sagnes
サニエ エリック
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How do you manage bare-metal local servers with nixops

[zimbatm]

Hi rohit,

Personally I just have a folder per machine with the /etc/nixos folder and
a little script that runs rsync + `nixos-rebuild --switch` on the target
machine.

Over time I will probably switch to using nixops as well but for a start
it's working super well for me. Especially since it doesn't have any nix
dependency on the source machine. It takes just a couple of seconds to
deploy which is way better than anything I had in the past (ansible,
puppet, capistrano, ...).
On Thu, 10 Dec 2015 20:45 Christoph Hrdinka  wrote:

> Hi Rohit!
>
> You can use nixops to deploy to any server running ssh. All you have to
> do is install a basic NixOS system with opensshd enabled on your target
> server. Then tell nixops the hostname/ip address of the new server
> via `deployment.targetHost`.
>
> Nixops will evaluate any nix expression you give it. If you supply
> multiple files these will be merged. Your nix expression must yield an
> attribute set of the following form:
>
> {
>   someMachineName =
> { config, lib, pkgs, ... }:
> {
>   deployment.targetHost = "hostname or ip";
>   # your usual nixos configuration file
>   # ...
> }
>
>   anotherMachine =
> {}
> }
>
> Every machine described in there will be deployed according to your
> configuation. Since it is a normal nix expression you can use any way
> to produce it. You can have basic templates that will be merged and
> overwritten by more specific ones, write everything in one file, spread
> it over hundret files or write a configuration syntax from which nix
> will derive all actual server configs.
>
> For what exactly do you need PXE? Is it for the initial NixOS install
> or do you want to use it because it worked for you till now with other
> systems?
> If you want it because of less configuration work it may be the wrong
> tool for a NixOS setup. Nixops is much better suited for this job than
> any PXE setup could ever be. It is made for simple deployment of
> hundrets of machines.
>
> You might also want to have a look at disnix/disnixos.
>
> Regards,
> Christoph Hrdinka.
> ___
> 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

Re: [Nix-dev] [call for] Release manager for Hydra

[Domen Kožar]

Thanks Christian and Aszlig, I'll talk to you on IRC in a couple of days.

On Sat, Dec 12, 2015 at 12:56 AM, Joachim Schiele  wrote:

> nice to hear that you want to do this.
>
> i've added a documentation about the setup process in the wiki, it can
> be found here:
>
> https://nixos.org/wiki/Installing_hydra_as_nixos_module
>
> On 11.12.2015 12:05, Christian Theune wrote:
> > Hi,
> >
> > ok. I can start with turning this into a checklist in the wiki. After
> > that I’d like walk through those things with someone.
> >
> > Things can take a while currently, as I’m on parental leave. :)
> >
> > Christian
> >
> >> On 08 Dec 2015, at 13:07, Domen Kožar  >> > wrote:
> >>
> >> Hey Christian,
> >>
> >> thanks. I had following in mind.
> >>
> >> Before the release:
> >>
> >> - check changelog is really up to date
> >> - mark any backwards incompatible changes
> >> - make sure all hydra tests pass
> >> - make sure the upgrade procedure works from previous release
> >> - test that setting up hydra from scratch works by following
> >> installation guide (this could be automated with NixOS test)
> >>
> >> At release time:
> >>
> >> - create a git (annotated) tag
> >> - mark the release date in changelog, etc
> >> - post a mail to nix-dev
> >>
> >> After release:
> >>
> >> - bump the package in nixpkgs
> >>
> >> I'm sure I forgot something, but we should document the process and
> >> improve it as we go.
> >>
> >> PS: we have a similar issue opened for
> >> NixOS: https://github.com/NixOS/nixpkgs/issues/4442
> >> PS: Eelco might know if there is something else that needs to be taken
> >> care of
> >>
> >> Domen
> >>
> >> Domen
> >>
> >> On Tue, Dec 8, 2015 at 12:54 PM, Christian Theune  >> > wrote:
> >>
> >> Hi,
> >>
> >> I *might* be able to. But I’m not sure I’m qualified enough. We’re
> >> using it at the company and rely on it, so this would be a good
> >> place to contribute back.
> >>
> >> Anyone willing to detail what is expected regarding QA in a bit
> >> more detail?
> >>
> >> Cheers,
> >> Christian
> >>
> >>> On 08 Dec 2015, at 12:06, Domen Kožar  >>> > wrote:
> >>>
> >>> So no one is willing to step up? This would benefit the whole
> >>> community and it's not a lot of work, mostly small housekeeping.
> >>>
> >>> On Wed, Nov 18, 2015 at 2:26 PM, Matthias Beyer
> >>> > wrote:
> >>>
> >>> On 18-11-2015 12:23:30, Peter Simons wrote:
> >>> > Domen Kožar writes:
> >>> >
> >>> >  > We need someone to volunteer to be a release manager.
> They would be
> >>> >  > doing QA that the release works and make sure changelog,
> docs, etc
> >>> >  > are updated.
> >>> >
> >>> > Also, we need a Hydra module for NixOS so that NixOS users
> can set-up
> >>> > Hydra easily through their configuration.nix file. Hydra
> provides such a
> >>> > module, of course, but the fact that it's living in a
> separate repository
> >>> > complicates matters a bit, particularly for newbies who are
> just getting
> >>> > started and who might try out NixOS mostly because of Hydra.
> We cannot
> >>> > expect them to mess with imports and fetchgit and channels
> and whatnot on
> >>> > their first day.
> >>> >
> >>>
> >>> Big +1 on this. I'd love to run my own hydra, but the lack of
> >>> a simple
> >>>
> >>> services.hydra.enable = true;
> >>>
> >>> -ish configuration keeps me away from this.
> >>>
> >>> --
> >>> Mit freundlichen Grüßen,
> >>> Kind regards,
> >>> Matthias Beyer
> >>>
> >>> Proudly sent with mutt.
> >>> Happily signed with gnupg.
> >>>
> >>> ___
> >>> nix-dev mailing list
> >>> nix-dev@lists.science.uu.nl  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
> >>
> >> --
> >> Christian Theune · c...@flyingcircus.io
> >>  · +49 345 219401 0
> >> Flying Circus Internet Operations GmbH · http://flyingcircus.io
> >> 
> >> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> >> HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune,
> >> Christian. Zagrodnick
> >>
> >>
> >
> > --
> > Christian Theune · c...@flyingcircus.io  · +49
> > 345 219401 0
> > Flying Circus Internet Operations GmbH · http://flyingcircus.io
> > 

Re: [Nix-dev] How do you manage bare-metal local servers with nixops

[rohit yadav]

Hi Zimbatm,

I have very similar arrangement. I use git and to keep the configuration
synced. However, I wish to use NixOps, I haven't been able to find time to
do that. From the documentation I could not figure out how to deploy on
bare-metal. But as Christoph mentioned that a simple Ip-Address in the
network is all you need with nixops do deploy. It will remove lot of boiler
plate configuration I have to write on each system.

Thanks,
Rohit

On Mon, Dec 14, 2015 at 3:33 PM, zimbatm  wrote:

> Hi rohit,
>
> Personally I just have a folder per machine with the /etc/nixos folder and
> a little script that runs rsync + `nixos-rebuild --switch` on the target
> machine.
>
> Over time I will probably switch to using nixops as well but for a start
> it's working super well for me. Especially since it doesn't have any nix
> dependency on the source machine. It takes just a couple of seconds to
> deploy which is way better than anything I had in the past (ansible,
> puppet, capistrano, ...).
> On Thu, 10 Dec 2015 20:45 Christoph Hrdinka  wrote:
>
>> Hi Rohit!
>>
>> You can use nixops to deploy to any server running ssh. All you have to
>> do is install a basic NixOS system with opensshd enabled on your target
>> server. Then tell nixops the hostname/ip address of the new server
>> via `deployment.targetHost`.
>>
>> Nixops will evaluate any nix expression you give it. If you supply
>> multiple files these will be merged. Your nix expression must yield an
>> attribute set of the following form:
>>
>> {
>>   someMachineName =
>> { config, lib, pkgs, ... }:
>> {
>>   deployment.targetHost = "hostname or ip";
>>   # your usual nixos configuration file
>>   # ...
>> }
>>
>>   anotherMachine =
>> {}
>> }
>>
>> Every machine described in there will be deployed according to your
>> configuation. Since it is a normal nix expression you can use any way
>> to produce it. You can have basic templates that will be merged and
>> overwritten by more specific ones, write everything in one file, spread
>> it over hundret files or write a configuration syntax from which nix
>> will derive all actual server configs.
>>
>> For what exactly do you need PXE? Is it for the initial NixOS install
>> or do you want to use it because it worked for you till now with other
>> systems?
>> If you want it because of less configuration work it may be the wrong
>> tool for a NixOS setup. Nixops is much better suited for this job than
>> any PXE setup could ever be. It is made for simple deployment of
>> hundrets of machines.
>>
>> You might also want to have a look at disnix/disnixos.
>>
>> Regards,
>> Christoph Hrdinka.
>> ___
>> 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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] How do you manage bare-metal local servers with nixops

[Domen Kožar]

You might want to test https://github.com/NixOS/nixpkgs/pull/11279

On Mon, Dec 14, 2015 at 10:45 PM, rohit yadav 
wrote:

> Hi Zimbatm,
>
> I have very similar arrangement. I use git and to keep the configuration
> synced. However, I wish to use NixOps, I haven't been able to find time to
> do that. From the documentation I could not figure out how to deploy on
> bare-metal. But as Christoph mentioned that a simple Ip-Address in the
> network is all you need with nixops do deploy. It will remove lot of boiler
> plate configuration I have to write on each system.
>
> Thanks,
> Rohit
>
> On Mon, Dec 14, 2015 at 3:33 PM, zimbatm  wrote:
>
>> Hi rohit,
>>
>> Personally I just have a folder per machine with the /etc/nixos folder
>> and a little script that runs rsync + `nixos-rebuild --switch` on the
>> target machine.
>>
>> Over time I will probably switch to using nixops as well but for a start
>> it's working super well for me. Especially since it doesn't have any nix
>> dependency on the source machine. It takes just a couple of seconds to
>> deploy which is way better than anything I had in the past (ansible,
>> puppet, capistrano, ...).
>> On Thu, 10 Dec 2015 20:45 Christoph Hrdinka  wrote:
>>
>>> Hi Rohit!
>>>
>>> You can use nixops to deploy to any server running ssh. All you have to
>>> do is install a basic NixOS system with opensshd enabled on your target
>>> server. Then tell nixops the hostname/ip address of the new server
>>> via `deployment.targetHost`.
>>>
>>> Nixops will evaluate any nix expression you give it. If you supply
>>> multiple files these will be merged. Your nix expression must yield an
>>> attribute set of the following form:
>>>
>>> {
>>>   someMachineName =
>>> { config, lib, pkgs, ... }:
>>> {
>>>   deployment.targetHost = "hostname or ip";
>>>   # your usual nixos configuration file
>>>   # ...
>>> }
>>>
>>>   anotherMachine =
>>> {}
>>> }
>>>
>>> Every machine described in there will be deployed according to your
>>> configuation. Since it is a normal nix expression you can use any way
>>> to produce it. You can have basic templates that will be merged and
>>> overwritten by more specific ones, write everything in one file, spread
>>> it over hundret files or write a configuration syntax from which nix
>>> will derive all actual server configs.
>>>
>>> For what exactly do you need PXE? Is it for the initial NixOS install
>>> or do you want to use it because it worked for you till now with other
>>> systems?
>>> If you want it because of less configuration work it may be the wrong
>>> tool for a NixOS setup. Nixops is much better suited for this job than
>>> any PXE setup could ever be. It is made for simple deployment of
>>> hundrets of machines.
>>>
>>> You might also want to have a look at disnix/disnixos.
>>>
>>> Regards,
>>> Christoph Hrdinka.
>>> ___
>>> 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 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