- Updated nixpkgs to commit 10d7f8d34e5eb9c0f9a0485186c1ca691d2c5922
- Updated nixos-unstable to commit c2a03962b8e24e669fb37b7df10e7c79531ff1a4
- Upgraded home-manager to release-25.05
- Added cudaSupport = true to Linux x64 CUDA package configuration
- Replaced `dnsResolvableName` with `hostname` in device configuration options
- Updated DNS record generation logic to use `hostname` instead of domain-based naming
- Removed deprecated `dnsResolvableName` option from network module
- Restructured DNS record templates to use consistent formatting
- Simplified code structure by removing redundant whitespace and reorganizing attribute definitions
- Updated `generateDeviceHostRecords` to use new naming convention and improved template syntax
- Changed RELEASE variable from 24.11 to 25.05 in the script
- This affects cached hash updates for the new release version
- No functional changes, only build configuration update
- Refactored config references from `config.architect.networks` to `config.pepe.core.network.interfaces` across multiple files
- Updated `fail2ban.nix`, `firewall.nix`, `tailscale.nix`, and `utilities.nix` to align with new configuration structure
- Centralized network interface configuration under `pepe.core` for better maintainability
- Maintained existing functionality while modernizing configuration hierarchy
Okay, let's see. The user wants to port the architect/headscale.nix to a module. The existing code is in the architect directory, and they want to move it to a module structure.
First, I need to understand what the original file does. It seems to be configuring Headscale with specific settings, ports, and vhost configurations. The new module should encapsulate these settings into a reusable module.
Looking at the diffs, the new module is created under modules/services/headscale.nix. The module defines options for enabling the service, package, domain, port, and settings. The config section sets up the service, vhost, and firewall rules.
The commit message needs to be concise. The type is 'refactor' because it's restructuring the code into a module. The description should mention moving the configuration to a module and making it reusable. Keeping it under 72 characters.
So, "refactor: move headscale configuration to a reusable module" seems appropriate. It starts with 'refactor', uses imperative mood, and is within the character limit.
</think>
refactor: move headscale configuration to a reusable module
