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

drop systemd service #551

Closed
cgwalters opened this issue Oct 27, 2023 · 6 comments · Fixed by #663
Closed

drop systemd service #551

cgwalters opened this issue Oct 27, 2023 · 6 comments · Fixed by #663
Assignees
Labels
enhancement New feature or request jira For syncing with Jira triaged This issue was triaged

Comments

@cgwalters
Copy link
Member

In Fedora and derivatives there's a policy I think of writing SELinux policies for things that are systemd .services.

We happen to have a .socket and .service units but we aren't really a service today. The socket actually denies non-root from connecting.

I think we should just delete those units and where we want to run things under systemd, we do it dynamically via systemd-run e.g.

The primary goal of this is to get this project off the list of things that need a SELinux policy.
But I think it'd be a good cleanup anyways.

@EyeCantCU
Copy link

Hello!

I've opened a pull request here: #586

Please let me know if there's anything that looks like it needs to be changed :)

@HuijingHei HuijingHei self-assigned this Feb 28, 2024
@HuijingHei HuijingHei added the jira For syncing with Jira label Feb 28, 2024
@travier travier added enhancement New feature or request triaged This issue was triaged labels Apr 16, 2024
@cgwalters
Copy link
Member Author

I think this still makes sense, yes.

@HuijingHei
Copy link
Member

Thanks @cgwalters for the confirmation, will look at this.

@HuijingHei
Copy link
Member

Hi @cgwalters, to drop .socket and .service units, should remove ipc mode, make all subcommand working like generate-install-metadata, instead of creating connection with ClientToDaemonConnection::new(), connect(), send(), and shutdown(), is this right? Thanks!

HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 22, 2024
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 22, 2024
@cgwalters
Copy link
Member Author

I typed this out, only compile tested but hopefully illustrates the idea

diff --git a/src/bootupd.rs b/src/bootupd.rs
index d0eef93..2cd11e6 100644
--- a/src/bootupd.rs
+++ b/src/bootupd.rs
@@ -408,8 +408,8 @@ pub(crate) fn print_status(status: &Status) -> Result<()> {
     Ok(())
 }
 
-pub(crate) fn client_run_update(c: &mut ipc::ClientToDaemonConnection) -> Result<()> {
-    let status: Status = c.send(&ClientRequest::Status)?;
+pub(crate) fn client_run_update() -> Result<()> {
+    let status: Status = status()?;
     if status.components.is_empty() && status.adoptable.is_empty() {
         println!("No components installed.");
         return Ok(());
@@ -420,9 +420,7 @@ pub(crate) fn client_run_update(c: &mut ipc::ClientToDaemonConnection) -> Result
             ComponentUpdatable::Upgradable => {}
             _ => continue,
         };
-        match c.send(&ClientRequest::Update {
-            component: name.to_string(),
-        })? {
+        match update(name)? {
             ComponentUpdateResult::AtLatestVersion => {
                 // Shouldn't happen unless we raced with another client
                 eprintln!(
@@ -450,9 +448,7 @@ pub(crate) fn client_run_update(c: &mut ipc::ClientToDaemonConnection) -> Result
     }
     for (name, adoptable) in status.adoptable.iter() {
         if adoptable.confident {
-            let r: ContentMetadata = c.send(&ClientRequest::AdoptAndUpdate {
-                component: name.to_string(),
-            })?;
+            let r: ContentMetadata = adopt_and_update(name)?;
             println!("Adopted and updated: {}: {}", name, r.version);
             updated = true;
         } else {
diff --git a/src/cli/bootupctl.rs b/src/cli/bootupctl.rs
index 3883a7a..3e1ae3d 100644
--- a/src/cli/bootupctl.rs
+++ b/src/cli/bootupctl.rs
@@ -1,6 +1,10 @@
+use std::os::unix::process::CommandExt;
+use std::process::Command;
+
 use crate::bootupd;
 use crate::ipc::ClientToDaemonConnection;
 use crate::model::Status;
+use crate::util::CommandRunExt;
 use anyhow::Result;
 use clap::Parser;
 use log::LevelFilter;
@@ -107,13 +111,15 @@ impl CtlCommand {
 
     /// Runner for `update` verb.
     fn run_update() -> Result<()> {
-        let mut client = ClientToDaemonConnection::new();
-        client.connect()?;
-
-        bootupd::client_run_update(&mut client)?;
-
-        client.shutdown()?;
-        Ok(())
+        let running_in_systemd = std::env::var_os("INVOCATION_ID").is_some();
+        if !running_in_systemd {
+            let r = Command::new("systemd-run")
+                .args(["--unit", "bootupd", "bootupctl", "update"])
+                .exec();
+            // If we got here, it's always an error
+            return Err(r.into());
+        }
+        bootupd::client_run_update()
     }
 
     /// Runner for `update` verb.

@cgwalters
Copy link
Member Author

Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon.

I think an important aspect of this is that we retain something like --unit bootupd which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.

HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 23, 2024
Fixes coreos#551

Get hints by coreos#551 (comment)
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 23, 2024
Fixes coreos#551

Get hints by coreos#551 (comment)
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 23, 2024
Fixes coreos#551

Get hints by coreos#551 (comment)
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 24, 2024
Fixes coreos#551

Get hints by coreos#551 (comment)
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 24, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 27, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 27, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 27, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 27, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 28, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 28, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 28, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 29, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 29, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
HuijingHei added a commit to HuijingHei/bootupd that referenced this issue May 29, 2024
Fixes coreos#551

Get hints by coreos#551 (comment),
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.

I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
travier added a commit to travier/selinux-policy that referenced this issue Jun 3, 2024
Bootupd is no longer using a systemd service and socket unit.

It is now called either directly from the command line by an
administrator or in the furture as part of the boot process in a oneshot
unit.

See: coreos/bootupd#551
travier added a commit to travier/selinux-policy that referenced this issue Jun 4, 2024
Bootupd is no longer using a systemd service and socket unit.

It is now called either directly from the command line by an
administrator or in the furture as part of the boot process in a oneshot
unit.

See: coreos/bootupd#551
evan-goode pushed a commit to evan-goode/workstation-ostree-config that referenced this issue Jul 24, 2024
With the following issues now fixed:
- coreos/bootupd#630
- coreos/bootupd#658
- coreos/bootupd#551

And corresponding support in Anaconda:
- rhinstaller/anaconda#5508

We can now (re-)enable bootupd for the bootable containers.

After a bit of testing, we will enable it for the classic ostree ones.

See: https://gitlab.com/fedora/ostree/sig/-/issues/1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request jira For syncing with Jira triaged This issue was triaged
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants