Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GNOME3 ISO, Don't run graphical installer ISOs as root #66313

Closed
wants to merge 7 commits into from

Conversation

worldofpeace
Copy link
Contributor

@worldofpeace worldofpeace commented Aug 8, 2019

Motivation for this change

I think it's a great idea to provide another graphical iso.
I've seen people turn away from nixos because they somehow thought the only DE
choice was plasma5.

This also renames the regular iso_graphical image to iso_graphical_plasma5.
We already definitely have to organize updating

to accommodate this.

Some of you may be interested in the ISO size and it's

  • 1.5 GB

Probably most important commit here is d3c9489.

The graphical installer will no longer use root, but a less privileged live user.
I'm going to quote the commit message here

There's many reason why it is and is going to
continue to be difficult to do this:

1. All display-managers (excluding slim) default PAM rules
   disallow root auto login.

2. We can't use wayland

3. We have to use system-wide pulseaudio

4. It could break applications in the session.
   This happened to dolphin in plasma5
   in the past.

Because of 1 and 2 it completely prevented me from doing this.
This change was already seen in #42610 and my opinion was received as reactive.
I hope this better supports my claim, this is going to be more work for us in the long run to maintain.

Now you could say the ISO should just use slim, but this project is abandoned and we really shouldn't be using it. Not to mention it wouldn't integrate at all with gnome.

Things done

I've ran the gnome and plasma5 iso's in qemu and they seemed to work fine.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

There's many reason why it is and is going to
continue to be difficult to do this:

1. All display-managers (excluding slim) default PAM rules
   disallow root auto login.

2. We can't use wayland

3. We have to use system-wide pulseaudio

4. It could break applications in the session.
   This happened to dolphin in plasma5
   in the past.

This is a growing technical debt, let's just use
passwordless sudo.
Note we're not using wayland default in the graphical media because it
could cause headaches for Nvidia users. But the session is still available.
And all the other things and paths to match it
Copy link
Member

@lheckemann lheckemann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I like it!

One concern I have is that this would add another big file to the release, and @edolstra may not like that.

nixos/doc/manual/installation/installing.xml Outdated Show resolved Hide resolved
@@ -30,15 +30,27 @@ with lib;
Version=1.0
Type=Application
Name=NixOS Manual
Exec=firefox ${config.system.build.manual.manualHTMLIndex}
Exec=firefox ${config.system.build.manual.manual}/share/doc/nixos/index.html
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did the manualHTMLIndex variant not work?

Thought on the side: maybe this should be extracted into the nixos manual module…

iso_graphical = forMatchingSystems [ "x86_64-linux" ] (system: makeIso {
module = ./modules/installer/cd-dvd/installation-cd-graphical-kde.nix;
type = "graphical";
iso_graphical_plasma5 = forMatchingSystems [ "x86_64-linux" ] (system: makeIso {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that renaming iso_graphical will break the NixOS channel generation script.

@edolstra
Copy link
Member

edolstra commented Aug 8, 2019

I'm not too keen on providing multiple graphical ISOs. Apart from the overhead this adds to the release process (in terms of storage costs and upload time), I'd rather have one well-tested ISO than multiple poorly tested ones. It also adds friction for new users since they have to decide which ISO to download, and it's not obvious which one is better.

@@ -8,6 +8,30 @@ with lib;
{
imports = [ ./installation-cd-base.nix ];

users.extraUsers.live = {
isNormalUser = true;
uid = 1000;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably shouldn't use UIDs in the >1000 range since that's reserved for users. Maybe just leave out the UID?

users.extraUsers.live = {
isNormalUser = true;
uid = 1000;
extraGroups = [ "wheel" "networkmanager" "video" ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are networkmanager and video needed? NetworkManager should work for locally logged-in users without it, and likewise logged-in users get access for /dev/video* via an ACL.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. I think I'd have an issue on my own installation if I didn't use this. I've received guidance that this should be done, but I've yet to verify this.

I will find out 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried this in a vm and it caused it to require authentication to initiate a connection with networkmanager. Not sure about video though but perhaps it's fine to leave it.

@edolstra
Copy link
Member

edolstra commented Aug 8, 2019

We could merge this without the changes to nixos/release.nix for now.

@worldofpeace
Copy link
Contributor Author

worldofpeace commented Aug 8, 2019

@edolstra
I'm not too keen on providing multiple graphical ISOs. Apart from the overhead this adds to the release process (in terms of storage costs and upload time), I'd rather have one well-tested ISO than multiple poorly tested ones. It also adds friction for new users since they have to decide which ISO to download, and it's not obvious which one is better.

Are we saying that manually testing these is the way to go?
Because if we had good automated tested for these it shouldn't be a problem how many ISO's we distribute, aside from the technical overhead. Additionally, I've put a lot of work into GNOME3 in NixOS, I'd like my work to be visible to users trying it. It's a good way to attract desktop users in general.

Additionally, any graphical ISO would be better for new users. And I'm not sure we'd be able to deduce one as being "better" plainly but better for a particular person's preference. I'd say it's simply another option of graphical ISO so I don't think it would cause to much trouble in the decision process.

@lheckemann
One concern I have is that this would add another big file to the release

Indeed it is a big file, but it's still smaller than other GNOME3 based iso's in the wild.

Examples

Though Opensuse Leap has somehow got it to 921 MB.

So I'd say, comparatively, it's in line with being one of the smaller ones.

@edolstra
We could merge this without the changes to nixos/release.nix for now.

I can see how we wouldn't want to block this on that, I respect your guidance if you think the technical overhead should cause us to consider carefully adding this to the release.

Copy link
Member

@samueldr samueldr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need all installer images to run under the same user. The minimal one included.

Otherwise, this may cause issues in writing documentation, and supporting users. Assumptions will be made "they are running ____" but instead they are running ____, thus the assumption doesn't hold and they need to either run through sudo or not.

Though, I'm not saying that graphical images must be run as root, only that all installers should use the same user, and relevant installation notes fixed, if needs be.

@worldofpeace
Copy link
Contributor Author

worldofpeace commented Aug 8, 2019

@samueldr Ah I overlooked that, I will move that to installation-device.nix etc.

Note I think the ova image uses a demo user already, but that was inconsistent before this.

* Move the config to installation-device.nix
* correct mingetty helpline

polkit config is still in graphical-base because
that is where polkit is useful.
* Don't use old users.extraUsers option.
* Don't set uid.
@worldofpeace worldofpeace added the 6.topic: GNOME GNOME desktop environment and its underlying platform label Aug 8, 2019
@ofborg ofborg bot removed the 6.topic: GNOME GNOME desktop environment and its underlying platform label Aug 8, 2019
@worldofpeace
Copy link
Contributor Author

So I've decided with some guidance from @grahamc that it would help me to split this into smaller PR's.

First one will be Don't run installer as root.
The other stuff will come after since this needs that change first.

@worldofpeace worldofpeace mentioned this pull request Aug 8, 2019
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants