1
0
Fork 0
Commit graph

15 commits

Author SHA1 Message Date
Jaroslav Škarvada
90c24eea03
new release (2.24.1)
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
2024-11-26 13:52:17 +01:00
Adriaan Schmidt
cddcd23369 dbus: add commands to dynamically create/destroy instances
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
2024-03-15 12:13:43 +01:00
Pavol Žáčik
db6b880bb6
Add API functions to retrieve active instances and their devices
Resolves: RHEL-15137

Appropriate commands are added to tuned-adm as well.

`get_instances`: Retrieves a list of active instances of a given
plugin or all active instances.

`instance_get_devices`: Retrieves a list of devices assigned
to a given instance.
2023-11-14 15:36:12 +01:00
Jaroslav Škarvada
33fae48515
Merge pull request #487 from evgeni/patch-2
update vendor_url in policy file
2023-02-08 02:01:27 +01:00
Jaroslav Škarvada
841a4ccd7f
API: add support for moving devices between instances
Extends the runtime API by the method:
  instance_acquire_devices(devices, instance_name)

E.g. consider the following TuneD profile:
[cpus_perf]
type=cpu
devices=cpu0, cpu1
governor=performance

[cpus_idle]
type=cpu
devices=${f:cpulist2devs:2-3}
governor=ondemand

[cpus_idle2]
type=cpu
devices=${f:cpulist2devs:4-5,7}
governor=ondemand

Notice that it's possible to use internal function 'cpulist2devs' to easily
specify cpulists.

After the following API call:
  instance_acquire_devices("cpulist:2-5,7", "cpus_perf")

It will result in cpu0 - cpu5 and cpu7 having the "performance" governor.

It's also possible to specify full device names in the API instead of the
cpulist, e.g.:
  instance_acquire_devices("cpu2,cpu3,cpu4,cpu5,cpu7", "cpus_perf")

In case the comma is part of the device name, it can be escaped by "\,".

In case the device name starts with the string "cpulist:", e.g. there is
by accident device named "cpulist:abcd", it's possible to use
"cpulist:cpulist:abcd" to escape it and don't recognize it as the cpulist.

The cpulist expand feature also supports bitmasks variant prefixed by the
0x and written as a string, e.g. "0xffffffff", i.e. all the standard
TuneD cpulist syntaxes are supported.

Resolves: rhbz#2113925

Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
2023-02-06 22:58:56 +01:00
Evgeni Golov
2885432926
update vendor_url in policy file 2022-12-21 21:20:00 +01:00
Jaroslav Škarvada
16d4acbaca
Project renamed to TuneD
The 'D' is now capital to clarify pronunciation.

DBus service name is kept as '/Tuned' not to break
backward compatibility.

This will also need update of downstream tests
which rely on the specific output strings containing
the name.

Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
2021-05-17 22:09:02 +02:00
Ondřej Lysoněk
9022920883 Make tuned-adm indicate which profile is post-loaded
Currently, the post-loaded profile is shown only among regular active
profiles. For example:

Current active profile: balanced post

This is not entirely user-friendly, because the user may not know why
the post-loaded profile is there, given that they did not specify it
in a 'tuned-adm profile' command and given that it's not present in
/etc/tuned/active_profile.

To give the user a hint about this and also to make it easy to see
exactly which profile is post-loaded, we make 'tuned-adm active' show
the following:

Current active profile: balanced post
Current post-loaded profile: post

Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
2020-06-08 17:58:22 +02:00
Thomas Renninger
cfbeb8e67e Lower permissions for plugin info dbus interfaces
As these interfaces allow loading and thus executing code from plugins
the default permission policy is lowered from:
yes:yes:yes
to
auth_admin:auth_admin:yes
So only users logged into the X server are allowed to use this interface
without extra root/admin authentication.

This was found by security review by Matthias Gerstner
<matthias.gerstner@suse.com>

Also see:
https://github.com/redhat-performance/tuned/issues/180
2019-05-03 13:13:38 +02:00
Tomas Korbar
e320c70d3d Move plugin and hint listing functionality into dbus 2018-12-05 12:18:48 +01:00
Ondřej Lysoněk
829c7de36c Support sending logs over DBus
Add two DBus calls:
log_capture_start(log_level, timeout)
 * This will instruct Tuned to create a new log handler, which will
   start writing log messages with level 'log_level' and higher to
   a buffer. The log levels are standard Python log levels (e.g.
   logging.INFO) or Tuned's custom log level LOG_LEVEL_CONSOLE which
   is defined as 60. The handler will be destroyed after 'timeout' seconds
   if contents of the buffer are not collected using log_capture_finish()
   before the timeout. If 'timeout' <= 0, log messages will be collected
   for as long as it takes before log_capture_finish() is called (use
   with care, so that you don't fill up memory with Tuned logs). This
   call returns a string ID of the log handler, a token, which should
   be passed to log_capture_finish().

log_capture_finish(token)
 * This will return (as a string) log messages collected by a log handler
   associated with the 'token'. It will also destroy the log handler.

These calls are privileged. They can only be called by the root user or
by a user logged in on a local console (just like the change-profile DBus
calls). This restriction is meant to prevent ordinary users from forcing
Tuned to allocate an insane amount of memory for the log buffers and crash
it (or other processes). In the future we may wish to replace this
restriction with a configurable policy which determines how many (and how
big) log buffers can a user with a given UID create. We may also want to
destroy the log handler when the original caller disconnects from DBus.

Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
2018-06-11 09:23:20 +02:00
Ondřej Lysoněk
cd655df597 Add 'tuned-adm profile_mode' command
Implement a new 'tuned-adm profile_mode' command, which prints
the current profile mode - automatic vs. manual.

Related: rhbz#1459146

Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
2017-08-03 15:24:17 +02:00
Ondřej Lysoněk
bc8ffcfb23 Introduce the concept of manually vs automatically set profile
A profile can now be set in two modes: automatic and manual.

When the automatic mode is active, Tuned always activates the
recommended profile upon startup. This mode can be set using
the following command:
tuned-adm auto_profile

When the manual mode is active, the previously applied profile
is activated upon startup. This mode can be set by switching
to the desired profile, e.g.
tuned-adm profile throughput-performance

The mode is saved on the second line of /etc/tuned/active_profile.

When the file /etc/tuned/active_profile does not exist, or is
empty, automatic mode is enabled. When the file has only one line,
i.e. it was generated by a previous Tuned version, manual mode
is enabled so that the upgrade doesn't cause unexpected active profile
changes.

Related: rhbz#1459146

Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
2017-08-03 15:23:54 +02:00
Ondřej Lysoněk
834dae9326 Allow running verify_profile_ignore_missing to all users
The policy for running the 'verify_profile_ignore_missing' D-Bus method
was missing, so only root could run it. This commit adds the policy, so
that it is the same as the policy for regular 'verify_profile'.

Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
2017-03-15 13:10:33 +01:00
Jaroslav Škarvada
68bb447a0f Implemented polkit authorization
Dropped dbus at_console policy and implemented polkit authorization.
By the default policy the query actions are allowed for all users, actions
which do modification to the system settings or Tuned state are by default
allowed only for active users that have console, others need admin
authorization.

Resolves: rhbz#1095142

Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
2016-06-10 11:57:33 +02:00