| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This one never was in use and it was WIP code to do a more fleshed out
mailserver configuration that should match an Ansible deployment of a
mailserver we had back then at OpenLab.
The machine was never in use (which is apparent from its configuration)
and I even *added* it to Vuizvui from "LaberNix" (Vuizvui's predecessor)
in 915e56fb4453b0701a423b0c96fb145318162ffd probably just for the sake
of completeness.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The former no longer exists and the latter has a new hardware and it's
self-managed by the owner now (which is always the best IMHO).
With both machines gone, we no longer need the "managed" profile and the
BFQ module that was used for the old hardware of Brawndo was no longer
used anywhere else. Same with the T100HA module, since Tyree was an ASUS
T100HA and apart from the module being probably very much outdated we
don't have another such hardware in Vuizvui.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
| |
They are current decomissioned, so no need to waste precious hydra
resources.
|
| |
|
|
|
|
|
|
| |
This is the old racker machine, but needs to be re-installed (hence the
updated stateVersion) and is renamed more consistently. This has not
much set up yet, trying to get binary cache up for the first install.
cc @aszlig, LMK if this is an unreasonable burden on the builders.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I already killed that machine on 2022-08-04:
tishtushi[~]0> cryptsetup erase /dev/sda2
WARNING!
========
This operation will erase all keyslots on device /dev/sda2.
Device will become unusable after this operation.
Are you sure? (Type 'yes' in capital letters): YES
tishtushi[~]0> cryptsetup erase /dev/sda3
WARNING!
========
This operation will erase all keyslots on device /dev/sda3.
Device will become unusable after this operation.
Are you sure? (Type 'yes' in capital letters): YES
Since some of the hardware was already broken (touchpad, keyboard, HDD,
SSD and webcam), I hardly doubt that I'll use it again so it makes sense
to remove the config here.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
| |
The machine no longer exists, so it doesn't make sense to continuously
build it on Hydra.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've already got a temporary laptop back then where I used the same name
and I introduced it in e73fcff03faed773df2500965cb9c4a4fcfbc04d and
subsequently removed it in 240378dcec205b78b32c329ff02eb9bea8af2c11.
With the new permanent hardware having arrived today, I decided to reuse
the name, because it sounds nicer than "tishtushi" (which is my crappy
laptop) and I also like the Slylandro Probes[1] a lot in Star Control.
The configuration here is pretty much bare-bones as we had before with
the temporary hardware and it's essentially a remix between dnyarri and
the old config, more to refine later...
[1]: https://wiki.uqm.stack.nl/Probe
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
| |
Mostly copied from haku
|
| |
|
|
| |
unused currently, may be replaced by something else
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in the initial commit (e73fcff03faed773df2500965cb9c4a4fc),
the machine was only temporary as a substitute for tishtushi.
Since slylandro had a pretty slow dual core CPU and its own quirks, this
was never a long-term solution and for the time being my intentions are
to work with dnyarri's new hardware until I have a less annoying setup
when I'm on the road again.
While writing this message, slylandro just died a gruesome death with
"cryptsetup erase", followed by "blkdiscard" on the whole drive.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
| |
Minimal configuration, just to get some cache going (that's at least the
idea). This should at least make having i686-linux builds worth
something :)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Tishtushi had a SSD failure and thus became a majoor nuisance to
work with, I got a temporary laptop from someone (since I don't know
whether they want to be mentioned, I leave out their name for now) in
order to be able to be more productive than waiting for several seconds
for a 1 KiB text file to be saved.
Right now, I'm not sure whether any firmware is needed for the temporary
laptop, so this is a hardware configuration just to get started with a
proper Hydra channel.
Signed-off-by: aszlig <aszlig@nix.build>
|
| | |
|
| |
|
|
| |
Shiny new machine needs NixOS love. <3
|
| |
|
|
| |
Small Hetzner qemu virtual server.
|
| |
|
|
| |
It’s not running at the moment.
|
| |
|
|
| |
Resolves #31
|
| |
|
|
|
|
|
| |
The 32-bit Hannstar Laptop was replaced by a Raspi with Raspian.
Removing the config means we don’t have to build any 32-bit software
in vuizvui anymore.
|
| |
|
|
|
|
|
| |
I'm bored of the names my machines have. Luckily NixOS makes changing
names as easy as changing underwear! So, let's use Valkyrie names
instead. Also, change the console font to something nicer, like the
default `Lat2-Terminus16` font!
|
| |
|
|
|
|
| |
This is a new work machine. The configuration is based off of `titan`
and `skunkworks`. I expect there to be plenty of changes in the future
as I get accustomed to it and shape it to my needs.
|
| | |
|
| |
|
|
|
|
|
|
| |
This machine was used for controlling the LED lighting bars at
Rockfabrik. I no longer work there and the machine has subsequently been
replaced by something else, so I don't need kzerza anymore.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
| |
both don't exist anymore
|
| |
|
|
| |
The namespace was kind of hard to remember, so let’s just call it openlab.
|
| |
|
|
| |
The machine’s mainboard broke, so it’s gone.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is only a placeholder right now so we get Hydra builds.
Signed-off-by: aszlig <aszlig@nix.build>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
This reverts commit dfd3d86562f09d812b330893cec053ab3d371bdf.
The machine is back on NixOS again :-)
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @brokkoliberta
|
| |
|
|
|
|
|
| |
Tyree is dead, no further comment...
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @brokkoliberta
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| | |
|
| |
|
|
|
|
|
|
| |
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>
|
| | |
|
| |
|
|
|
|
|
| |
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>
|
| |
|
|
| |
Only some machines should get the full config (with all packages).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
one can easily tell I don't currently use the vuizvui channel.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
