dell-command-configure: init at 4.2.0 with module #84926
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
endocrimes
suggested changes
Apr 10, 2020
|
Thanks, fixed up. |
teto
reviewed
Apr 10, 2020
|
Nice job.
I know the feeling. it is impressive and at the same time very scary :) |
teto
reviewed
Apr 12, 2020
| environment.systemPackages = [ pkgs.dell-command-configure ]; | ||
|
|
||
| system.activationScripts.dellCommandConfigure = | ||
| '' |
There was a problem hiding this comment.
hum I believe activationScript should be avoided as it can easily break things . Also the script creates states as the folders won't be removed afterwards
I am no systemd expert but greping nixpkgs, it can create folders in a way that's more fit.
RuntimeDirectoryPreserve = "yes";
LogsDirectory = subDirs [ "qemu" ];
RuntimeDirectory = subDirs [ "nix-emulators" "nix-helpers" "nix-ovmf" ];
StateDirectory = subDirs [ "dnsmasq" ];
There was a problem hiding this comment.
Managing directories with a oneshot systemd unit felt weird, but so did the solution I went for. I guess I would end up here with something like?
ExecStartPre = "mkdir -p /opt/dell/srvadmin/etc";
ExecStart = "ln -fs ${configFile} /opt/dell/srvadmin/etc/omreg.cfg";
LogsDirectory = "openmanage";
StateDirectory = "openmanage";
And remove the configuration options? Though I am unclear on how the symlink and directory would be cleaned up in this case.
As is, this matches how Dell Command Configure is distributed. If openmanage/srvadmin were to be packaged for NixOS, it would be more correct to pull srvadmin-hapi out and have it as a dependency, though I haven't done any testing on whether dcc depends specifically on the version it is distributed with. Latest version of srvadmin-hapi is 9.4.0 The deb and rpm packages additionally come with a systemd service to preload some drivers, but when getting this to work, it was unnecessary to get things to work. As this service works via a complex oneshot shell script I opted to leave it out, but it might prove necessary for some combinations of systems. See: DCC https://www.dell.com/support/article/us/en/19/sln311302/dell-command-configure Documentation https://www.dell.com/support/home/us/en/dedhs1/product-support/product/command-configure-v4.2/docs Openmanage http://linux.dell.com/repo/hardware/omsa.html
Creates the necessary configuration file to launch cctk. The cfg file is mostly undocumented, and while cctk appears to run fine with just `hapi.vardatapath` set, but this is (approximately, minus nix-related changes) what is distributed with the package. The program never actually wrote to those paths in my testing, and appears to operate just fine with only that one variable set, but I did not extensively test every single option, and certainly not across every system that is supported by the software.
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation for this change
My motivation here was configuring UEFI/BIOS settings on Dell laptops without rebooting (specifically I wanted to avoid the touchscreen UEFI my XPS 13 has).
I am not confident that the module (specifically the use of
activationScripts) is the best way to do what's needed.cctkhas no way of specifying where the configuration file is and I couldn't really find a convenient precedent in the nixpkgs repository. Would appreciate help or hints on whether it's possible to improve this!The package I wrote matches the way Dell distributes it, but if Openmanage was packaged for Nix, it would make sense to turn
srvadmin-hapiinto a dependency, and turn the module into a generalopenmanagemodule as all related services use the same configuration path. This felt like an ok approach considering the dependency is entirely unusable outside of it right now, and this meets the requirements.If a test for this kind of package is relevant, I would be happy to write one! I'm unsure as to what the best way towards it is though. As this service depends on hardware access, the extent of the test would be running
cctk --Versionreally.The package also requires that a UEFI setting be disabled ahead of time (SMM Security Mitigation). I'm not sure if this is something that should be mentioned to the user during installation, or put somewhere in the module description, etc.
Hope the description helps with reviewing :)
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)