about summary refs log tree commit diff
path: root/machines/default.nix
Commit message (Collapse)AuthorAgeFilesLines
* machines: rename labnet to openlabProfpatsch2018-06-051-2/+2
| | | | The namespace was kind of hard to remember, so let’s just call it openlab.
* machines/labnet: remove labtopProfpatsch2018-06-051-1/+0
| | | | The machine’s mainboard broke, so it’s gone.
* machines/labnet: pull hannswurscht into its own fileProfpatsch2018-06-051-2/+3
|
* machines/profpatsch: add mikiyaProfpatsch2018-05-231-0/+1
|
* machines: Add new machine "shakti"aszlig2018-04-121-0/+1
| | | | | | This is only a placeholder right now so we get Hydra builds. Signed-off-by: aszlig <aszlig@nix.build>
* machines: Remove arilouaszlig2018-04-031-1/+0
| | | | | | | | | | Why do I fix up a machine that doesn't exist anymore? This was from a time where I had no laptop and was travelling around with an USB stick in order to have a working environment on other machines, but that's no longer the case. Signed-off-by: aszlig <aszlig@nix.build>
* Revert "machines: Remove tyree"aszlig2018-02-021-0/+1
| | | | | | | | | This reverts commit dfd3d86562f09d812b330893cec053ab3d371bdf. The machine is back on NixOS again :-) Signed-off-by: aszlig <aszlig@nix.build> Cc: @brokkoliberta
* machines: Remove tyreeaszlig2017-12-111-1/+0
| | | | | | | Tyree is dead, no further comment... Signed-off-by: aszlig <aszlig@nix.build> Cc: @brokkoliberta
* Move devhell's machines into machines/aszlig2017-06-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In his configuration he had machine_common.nix which was imported from the other machine_*.nix files. However in order to start modularizing I've converted machine_common.nix into a proper NixOS module which now resides in modules/user/devhell/profiles/base.nix and can be simply activated via: vuizvui.user.devhell.profiles.base.enable = true; Apart from that I've removed the following configuration definitiens from machine_common.nix: nix.binaryCaches = [ "https://headcounter.org/hydra/" "https://cache.nixos.org/" ]; nix.requireSignedBinaryCaches = true; nix.binaryCachePublicKeys = [ "headcounter.org:/7YANMvnQnyvcVB6rgFTdb8p5LG1OTXaO+21CaOSBzg=" "cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=" ]; nix.nixPath = lib.mkOptionDefault [ "nixpkgs=/home/dev/git/remote/other_github/nixpkgs" ]; The reason for removing them is because we already handle that via the vuizvui core modules (modules/core/common.nix). I've tested this by evaluating the machines by temporarily setting "allowUnfree = true" (which is part of another module I didn't migrate yet) and it succeeds. Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @devhell
* machines/mmrnmhrm: Merge machine into dnyarriaszlig2017-04-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, mmrnmhrm has died because of three blown up capacitors which resulted in hard shut downs due to CPU0 temperature values that were out of range. At first I assumed a real temperature problem and thus vacuumed the fan and everything else, applied new thermal paste and it still failed after a few minutes. What I found a bit odd was the fact that the machine powered off even though the last reading of the CPU temperature was 40 degrees Celsius, so that definitly wasn't the problem. So I went on to look for any blown capacitors on the main board, because that's probably one of the most frequent cause of hardware failure... at least for mainboards and monitors. One of the three capacitors I found to be leaking seems to be leading to the CPU temperature sensor as far as I can tell (I didn't test with a multimeter though, because I have lent it out to someone else). While it shouldn't be hard to fix the blown capacitors (apart from the fact that we had national holiday during the Easter week), my long-term goal was to make mmrnmhrm obsolete anyway, so it was a good opportunity to do exactly that. The reason why I wanted to get rid of mmrnmhrm was that it has been a very slow machine since commit 2df7ee103a01da34c9c82235bc286dde35e0f1ba, which was essentially a hardware downgrade back then. Dnyarri always has been the better machine hardware-wise but I couldn't use it to its full potential because it had a cooling issue. The latter has been resolved a few weeks ago, where I replaced the CPU fan and it's now not only less noisy but stays at below 50 degrees Celsius even on high load. Merging mmrnmhrm into dnyarri also means, that we now have a new disk layout: +---------------+--------------+--------------+--------------+ | Disk 1 | Disk 2 | Whole disk 3 | Whole disk 4 | +---------------+--------------+--------------+--------------+ | EFI partition | crypt-vault | crypt-root-3 | crypt-root-4 | | crypt-swap-1 | crypt-swap-2 +-----------------------------+ | crypt-root-1 | crypt-root-2 | +---------------+--------------+ Disk 1 and 2 use GUID partitions while disk 3 and 4 don't have a partition table but use btrfs across the whole device. The crypt-vault partition is solely for unlocking other crypto volumes so that a single passphrase unlocks all of the LUKS containers rather than needing to provide 6 passphrases. Also, I've migrated to using UEFI for booting, which is why there now is an EFI partition as well. Having no redundancy on the EFI and the crypt-vault partitions doesn't hurt so much because in the event of drive failure all of the containers can still be unlocked via a passphrase instead of the vault key. Disk 3 and 4 are the disks that were formerly installed into mmrnmhrm and now comprise one big btrfs volume together with the two disks (1 and 2) already present inside dnyarri. Instead of RAID1 on data and metadata, the btrfs file system layout now is RAID10 for data and metadata. This merge also removes synergy for obvious reasons (no other machine anymore) and disables kmscon because it was just a test in the first place and I found it a bit annoying to work with. Summary: Mmrnmhrm is (are?) dead, long live dnyarri! Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Remove notsureaszlig2017-02-161-1/+0
| | | | | | | | This machine hasn't been in use since a year or even longer and the successor machine (brawndo) is already in use since a while, so we can safely drop the machine. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines.profpatsch: add hakuProfpatsch2017-01-251-0/+1
|
* machines: Add new machine "meshuggah"aszlig2017-01-121-0/+1
| | | | | | | | Currently only a very minimal base configuration, nothing too fancy yet. The machine is going to serve as a audio/media server in my living room. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines/schaf: electric sheep dream of other people's computerssternenseemann2016-11-041-0/+1
|
* Add new machine "brawndo" to the managed machinesaszlig2016-07-231-0/+1
| | | | | | | This one more or less shares the same profile as "notsure", but I'm too lazy right now to consolidate and/or modularize everything properly. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines/labtops: don’t build full configProfpatsch2016-07-081-3/+1
| | | | Only some machines should get the full config (with all packages).
* Revert adding dummy machine "gitit-stub"aszlig2016-06-141-1/+0
| | | | | | | | | | | | | | This reverts commit 65435d827c846ab2eef966601cd0490591b8dbe9. Commit d730df7 fixed the meta.hydraPlatforms attribute, so the generic channel now should build the patched gitit version as part of its constituents and we don't need a dummy machine just for that anymore. Other than that, the package now also gets built as a separate job to allow for one-click installs. Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @Profpatsch
* machines/gitit-stubProfpatsch2016-06-131-0/+1
| | | | | | | | | | | | | According to 302fb4f4bc0213b231b9bf5b98093c60d3917313 the package should be included in the hydra build, but it is not usable, because there is no channel that waits for the gitit build to succeed. This stub exists until someone finds out how to create such a channel (aka the channel building mechanism is documented in a way that it can be used by people not deeply familiar with both nixpkgs and hydra). cc @aszlig
* machines: added schnurrkadselukasepple2016-06-051-1/+2
| | | | one can easily tell I don't currently use the vuizvui channel.
* machines: Remove machine "website-vm"aszlig2016-05-281-1/+0
| | | | | | | | | | | | | According to @Profpatsch the whole point of this dummy machine was that the patched gitit version should be built on Hydra. We don't need to have such workarounds, because we're already recursing through all packages in the Vuizvui namespace whether meta.platforms includes a system that we support on our Hydra. This has been done with a4d6395 so "website-vm" is obsolete now. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines/labnet: init website-vmProfpatsch2016-05-201-0/+1
|
* machines/labtops: Rename config expression fileaszlig2016-05-031-1/+1
| | | | | | | | It doesn't list a single machine and the profile module also uses the pluralized version, so let's pluralize the file name as well. Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @Profpatsch
* lib/call-machine: Get rid of extraConfig attributeaszlig2016-05-031-1/+1
| | | | | | | | | | | | Right now we're not using the system attribute at all and we can still use nixpkgs.system to set the attribute for a particular machine. So we now can pass configuration attributes to the second argument of callMachine *directly* instead of using specific subattributes, which I think feels is a more natural way so users don't need to look up that "extraConfig" is for adding configuration values. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* lib: Rename callMachines to callNetworkaszlig2016-05-031-1/+1
| | | | | | | | This is to name it closer to what NixOps calls a network expression, so that it's clear that there is more abstraction going on like setting the hostname rather than just being a plain mapAttrs over callMachine. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* Move callMachines into lib/aszlig2016-05-031-16/+2
| | | | | | | | We now no longer need to import the call-machine.nix directly but now can use import <vuizvui/lib> in order to get *both* the callMachine and the callMachines function. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines/labtops: Switch to use callMachinesaszlig2016-05-031-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Should make the configurations much more easy to read. I did a small comparison between the machine derivations of the old Labtop and the Labtop with the new callMachines implementation using: diff -U 0 =(nix-store -qR old_labtop.drv | sort -t- -k 2) \ =(nix-store -qR new_labtop.drv | sort -t- -k 2) The following store paths were different in the output: /nix/store/...-etc.drv /nix/store/...-initrd.drv /nix/store/...-kernel-modules-shrunk.drv /nix/store/...-nixos.conf.drv /nix/store/...-nixos-system-labtop-16.09pre82222.fc92bbf-vuizvui.drv /nix/store/...-stage-1-init.sh.drv /nix/store/...-system-units.drv /nix/store/...-unit-systemd-modules-load.service.drv This is okay and is due to the reversed module evaluation order, because we now have the module definition enabling the Labtop profile in extraConfig instead of in the root config. Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @Profpatsch
* machines: Add a new callMachines functionaszlig2016-05-031-0/+11
| | | | | | | | | | | | This is particularly needed for the Labtops and it allows to call a full attribute set of machines to be incorporated into a single file as one big attribute set. Its functionality is kind of similar to the NixOps network expressions by providing default hostnames (in our case with a priority of 900 to still make it overridable without pain). Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines/labnet: generic labtop configProfpatsch2016-04-251-1/+2
| | | | | Draws out the general config for all Labtops in its own module and creates a structure to specify the setting which are different.
* Remove all references to "heinrich"aszlig2016-03-051-2/+1
| | | | | | | | | This was a very old effort to NixOSify "heinrich" which unfortunately didn't happen and I'm not sure whether "heinrich" even exists anymore. The tests were broken anyway, so I doubt anyone would grief over it. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines/haenk: Machine is obsolete, remove itaszlig2016-02-231-1/+0
| | | | | | | | Obsoleted by tyree, even though tyree isn't fully working yet it doesn't make sense to build a lot of stuff just for a machine that doesn't get updated anymore. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* profpatsch: remove insane experimentProfpatsch2016-02-081-1/+0
|
* profpatsch: sane experimentProfpatsch2016-02-081-0/+1
|
* machines: Add new managed machine "tyree"aszlig2016-01-131-0/+1
| | | | | | | | | | | | | Currently this is just a somewhat basic configuration, because the hardware (an ASUS T100HA) is going to get us in trouble. For example right now not even the display is working correctly, neither is WiFi, but we're going to fix that real soon[TM] :-) The configuration is pretty much based on the "haenk" config, which this machine will replace once everything is working. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines/aszlig: Add managed machine "haenk"aszlig2015-12-271-0/+1
| | | | | | | Another machine I manage for someone else, currently nothing too fancy or complex here yet, except that it's very old hardware. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* Add missing ;lukasepple2015-12-191-1/+1
| | | | Not my day I guess. Aahhhhhhh
* Add missing {}lukasepple2015-12-191-1/+1
| | | | I am stupid
* Add fliewatuet to machines/default.nixlukasepple2015-12-191-0/+3
|
* lib/call-machine: Clean up expressionaszlig2015-12-151-11/+11
| | | | | | | | | | | | | | | This gets rid of the use attribute, which is now called "config". We had the "config" attribute before but it was kinda pointless, because it was just the import of the path and nothing else. So the config attribute now is the machine configuration with all of the vuizvui modules imported as well. The "build" attribute is now called "eval", which is more appropriate, because it's the evaluation of the configuration and not the finished system build. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Move callMachine function to lib/.aszlig2015-12-101-63/+1
| | | | | | | | The function is gettin rather large, so it makes sense to move it into another file so that the default.nix in machines/ won't be cluttered up with all the implementation-specific details. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Add attribute to build a VM.aszlig2015-12-101-0/+4
| | | | | | | | | | | | | | This is to make it easier testing various vuizvui machine configurations for example with my machine "mmrnmhrm" by using the following command: nix-build machines -A aszlig.mmrnmhrm The build product is a VM that can be started using: ./result/bin/run-*-vm Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Add a new managed machine "notsure".aszlig2015-12-101-0/+3
| | | | | | | I've added a "managed" namespace here, which should include all machines that are not my own but I manage for other people. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Patch "nomodeset" out of iso-image.nix.aszlig2015-12-051-1/+6
| | | | | | | | | | | | | | | | | | | | | This is a very hacky approach, because patching that file also requires us to patch the imports it's referencing. The first reason why I needed to patch is that there is no "modeset" you can add to kernelParams and re-enable modesetting that way. And the second reason is because we don't have something like mkRemove or mkFilter in the module system, so we could filter out items from a list. Another option here would be to mkForce-override the kernelParams, which would imply that we'd need to duplicate a lot of these options (for example init=...). So in the long run we surely need to have a better way to override lists, but until that I'm leaving it with the patched approach. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Remove /boot options from ISO images.aszlig2015-06-291-1/+7
| | | | | | | | We can't really do a "mkForce {}" or "mkForce null" on the submodule type and the upstream module throws an error on null values, so we simply define a dummy fileSystem with the noauto option set. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Properly override ISO configuration.aszlig2015-06-291-9/+19
| | | | | | | | | | | | | | | | | | | | | | We now do it the exact opposite way than introduced in 27dce7b. Instead of evaluating the machine config and stripping off the options we don't want to conflict with the iso-image.nix module, we now wrap the iso-image.nix module itself and just mkForce the values we don't want to collide. The reason for this is that the previous implementation just didn't work because dependent module options from the machine config (for example config.system.build.*) were already evaluated and thus we end up with overriding configuration options but get an initrd with the machine options (which we actually want to override) instead of the fileSystem/boot options that come with the iso-image.nix module. Although I'm not quite happy with this approach, it's still better than the old one and if iso-image.nix gets conflicting options we at least get a better error message rather than the definitions simply being stripped off. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Set a proper boot loader label for ISOs.aszlig2015-06-281-0/+1
| | | | | | Introduced in NixOS/nixpkgs@f9bd72f24cfc8c160d144615522b0bc692cde9d0. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Allow to easily build ISO images.aszlig2015-06-271-1/+27
| | | | | | | | | | | | | I know it's a somewhat hacky approach to strip off "_module", "boot.loader" and "fileSystems" from the machine config, but that should be the options which are to be set by iso-image.nix but that way we can re-use the upstream module. Also, if one of our modules sets an option without a proper "vuizvui." namespace, we get an error as well. But it's our policy anyway to always namespace with "vuizvui." so it's even good to get an error here. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* Integrate machine into vuizvui.Profpatsch2015-04-301-0/+3
|
* Handle all <nixpkgs> paths with nixpkgs-path.nix.aszlig2015-04-291-1/+1
| | | | | | | | | This file is just defaulting to <nixpkgs>, but we're going to substitue it by the channel generator. We also need to make sure that we don't have any other references to <nixpkgs>, but the latter can best be done on Hydra's side if we don't make <nixpkgs> available to vuizvui builds. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* machines: Add an "use" attr for configuration.nix.aszlig2015-04-011-0/+3
| | | | | | | | Useful to call the machine from configuration.nix like this: (import <vuizvui/machines> {}).aszlig.mmrnmhrm.use Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* Move last machine from labernix to vuizvui.aszlig2015-03-181-0/+3
| | | | | | | | | | | | I've moved the restrictions config of Postfix into the default module for now and actually fixed it so that it's actually working (the config value wasn't set before). Also, the option type was incorrectly set to types.list, which aliases to types.listOf and expects another function (kind) as its argument. This marks the end of LaberNix and the beginning of a new Vuizvui! Signed-off-by: aszlig <aszlig@redmoonstudios.org>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-09 17:14:14 +0000