Idiomatic way to make persistent configuration changes

[slavoutich]

Hi all,

I wonder what is an idiomatic way to make persistent changes in OpenSUSE. Examples of changes I am talking about are following:

• I use this trick to enter my disc encryption password only once during boot. The problem comes from the fact, that I must set */boot *
  mode to 700, and after an upgrade it gets gentley fixed back to 755, which may be a security problem at some point. - In order to make audio controls properly working on my laptop, I need to update /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common
  (yeah, fresh hardware). But this edit can also be wiped at some upgrade, which are frequent for Tumbleweed.

Thanks in advance!

[jetchisel]

Hi,

I’m not a tumbbleweed user, but here goes, the first problem you have is with permission so have a loot at the file /etc/permissions.

cat /etc/permissions

The file has some explanations at the top.

The second problem you’re having is with the config file being updated back to the original version/setup. The only idea that comes to mind is using a daemon that tracks the changes of that file in real time, well maybe not that real but you get the idea and then replace/edit it with your own config in real time as well. the utily **inotify-wait **which is part of the package inotifyt-tools can probably do what you want. Now systemd took over everything so maybe there is a way with systemd as well but that’s a hack so maybe some one knows how to do it without a daemon.

[nrickert]

@slavoutich

The problem comes from the fact, that I must set */boot *mode to 700, and after an upgrade it gets gentley fixed back to 755, which may be a security problem at some point.

I’m puzzled by the advice to change permissions on “/boot”. That really should not matter, as long as the “initrd” itself is readable only by root.

Personally, I just enter the passphrase twice – except in one virtual machine where I experiment with the suggested method.

[tsu2]

Although you should still make a backup of the file,
You can enter commands as you would have invoked in a console into the the following file which is read on bootup and commonly used to modify system defaults (typically kernel settings, network settings) but can really be used for just about anything

/etc/sysctl.conf

You can also read the MAN pages for
sysctl.conf
sysctl (the command)
sysctl.d (files read by the sysctl service, maybe this is where systemd wants you to place your commands)

Note that somewhere I read that /etc/sysctl.conf itself is scheduled to be deprecated sometime which IMO would be extremely surprising, but the other “conf” files listed in MAN sysctl.conf weren’t mentioned.

TSU

[tsu2]

@slavoutich

Hi all,

I wonder what is an idiomatic way to make persistent changes in OpenSUSE. Examples of changes I am talking about are following:

• I use this trick to enter my disc encryption password only once during boot. The problem comes from the fact, that I must set */boot *
  mode to 700, and after an upgrade it gets gentley fixed back to 755, which may be a security problem at some point. - In order to make audio controls properly working on my laptop, I need to update /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common
  (yeah, fresh hardware). But this edit can also be wiped at some upgrade, which are frequent for Tumbleweed.

Thanks in advance!

For these specific issues…
The first can be addressed using the permissions file jetchisel recommends, like the well known “/etc/profile” you can make a “/etc/permissions.local” file which will over-ride the default and won’t be over-written by an upgrade.

The second is more problematic.
You didn’t say exactly what you edited and how which may be important, but in general a “normal” update shouldn’t cause a configuration over-write but a “forced” or complete replacement could overwrite.

You can try to address these problems individually, but the sysctl.conf solution I posted should generally work… but of course, make a backup in case things don’t work as they should.

TSU

[arvidjaar]

@slavoutich

In order to make audio controls properly working on my laptop, I need to update /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common (yeah, fresh hardware). But this edit can also be wiped at some upgrade, which are frequent for Tumbleweed.

Documented solution is to have your own custom path and profile definitions for your card and tell PA to use them. They will be preserved on update.

https://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/Profiles/

[slavoutich]

Thanks a lot, guys, a lot of useful info really helpful!

@jetchisel

Hi,

I’m not a tumbbleweed user, but here goes, the first problem you have is with permission so have a loot at the file /etc/permissions.

Thanks, this is indeed the solution I looked like, really helpful. Didn’t meet this file before in other distros.

@nrickert

I’m puzzled by the advice to change permissions on “/boot”. That really should not matter, as long as the “initrd” itself is readable only by root.

Agree, but probably initrd inherits permissions of its directory (didn’t double-check, so don’t beat me up if it is wrong :))

@tsu2

You can enter commands as you would have invoked in a console into the the following file which is read on bootup and commonly used to modify system defaults (typically kernel settings, network settings) but can really be used for just about anything

/etc/sysctl.conf

Good trick, though it couns for me as rather “hacky” than “idiomatic”

@arvidjaar

Documented solution is to have your own custom path and profile definitions for your card and tell PA to use them. They will be preserved on update.

Profiles

May be it will work, Arch wiki suggests that the only way is to edit the file, but may be still wrong Need to do a bit of reading/thinking on how ALSA/PulseAudio work.

In general, under “idiomatic” solution me, coming from the Gentoo world, would be something like custom patches there: when installing a package, it will prepare the source code, apply all suitable user patches from /etc/portage/patches and then compile it. I wondered if suddenly something like that exists in OpenSUSE.

[malcolmlewis]

@slavoutich

Thanks a lot, guys, a lot of useful info really helpful!

Thanks, this is indeed the solution I looked like, really helpful. Didn’t meet this file before in other distros.

Agree, but probably initrd inherits permissions of its directory (didn’t double-check, so don’t beat me up if it is wrong :))

Good trick, though it couns for me as rather “hacky” than “idiomatic”

May be it will work, Arch wiki suggests that the only way is to edit the file, but may be still wrong Need to do a bit of reading/thinking on how ALSA/PulseAudio work.

In general, under “idiomatic” solution me, coming from the Gentoo world, would be something like custom patches there: when installing a package, it will prepare the source code, apply all suitable user patches from /etc/portage/patches and then compile it. I wondered if suddenly something like that exists in OpenSUSE.

Hi
Sort of, it’s called OBS openSUSE Build Service but we live in the world of RPM’s… There are tools to build things like perl, python modules etc. Then there are services to pull from git, but not a repository for all patches, quilt can be used but as long as the patch is present in the rpm build directory and %autosetup macro is used, it will apply them.

[malcolmlewis]

Hi
For your permissions issue, create a file in /etc/permissions.d then it won’t get overwritten when permissions update, there are some examples in that directory.