Running sudo commands within a specific script after boot, without password

English Install/Boot/Login
#1

Hello, I am having a little bit of dilemma
I need to run

sudo alsactl init

after the computer boots and after KDE has fully booted.
I tried putting the command in the
/etc/init.d/boot.local

but that actually interrupts the boot, but does not actually initializes the module as I wish to.

Is there a way to permit ONE time only within one script under sudo without password during/after boot?

Thank you for your time. I’ve done this before but I am having a little bit of brainfart
-SJL

#2

What you did awhile back may no longer work today.

About 3 years ago, like many other distros openSUSE began replacing the SysVinit system (ie base on init files) with systemd. Only some init functions might still work but as time goes on, they are all being replaced with systemd commands.

There are various ways to invoke your script automatically…

  • If your script runs best after User login, particularly if it relies on some User configuration completed… You can generally hook those into the Desktop configuration files. Of course, this requires foreknowledge of the running Desktop.
  • If your script runs best during system boot, then you can determine when during the boot, find the systemd Unit file that manages that service startup and add your script.
  • Create a systemd Unit file that invokes your script. When you create your own Unit files, you generally inspect what already exists, find something that is similar to what you want, copy and rename it to /etc/systemd/user/

I personally prefer that last option because it keeps your custom script separate from everything else.
Note that you should never edit original systemd Unit files, you should always copy anything you want to modify to /etc/systemd/systemd/ or /etc/systemd/user/
If the system finds a Unit file with the same name in these locations, it will automatically over-ride the original files.
This way you minimize borking your system with bad changes, and can always undo changes by simply removing your Unit file thereby re-activating the original file.
You’ll find this and much more reading about systemd Unit files.

TSU

#3

The real question here is; why do you need to do this?

Sounds like ALSA is not loading the right module for your sound card, in this case you should fix the issue by creating a .conf file that contains the suitable module (or change the options, or blacklist an offending module) instead of using a hack like this.

#4

TSU, I have a script

#!/bin/sh
sudo alsactl init

I actually tried directly copying that into /etc/systemd/user
and it didn’t work, I also tried activating it with chmod 777 and chmod 666, and unfortunately neither of them seem to work.

Miuku, ideally, if I could make the proper driver to load on boot, that would be the best, I actually started a thread for it, but the best answer I was given was to upgrade to LEAP 42.3.

That is not an option right now, I will do that as well as moving onto Windows 10.

#5

To me it looks as if you want to run something at system boot through systemd. If I understand that correctly, then why the sudo? The systemd scripts at boot all run “as root” already.

#6

I missed that you’re running some old, likely unsupported version of openSUSE.
Which openSUSE version are you running?

SOP:
First launch alsactl manually to make sure it works.
Then, consider if there is any benefit to running automatically, from its description alsactl only gives you access to advanced functions. Do you know the exact command to do whatever you want since simply launching isn’t likely enough to do anything?

As I described, you don’t just place a script in /etc/systemd/user/, Unit files are configuration files, not executables. Unit files are are read and contain commands like ExecStart to execute scripts and binaries.
You should browse existing Unit files like those you will find at /usr/lib/systemd/system/, pick one that you like and use it as a template by copying it to /etc/systemd/user/, rename it to make it your own and modify the file contents to execute your script.

TSU

#7

I missed that also :(.

	@SJLPHI

The forums software require you to specify the openSUSE version you use. When you have to choose OTHER VERSION because your run an unsupported one, we of course still (or even more urgently) want to know which version!!

#8

Sorry, I’ve been very busy.

I run OpenSUSE 13.2 KDE

I do intend to do a full upgrade to LEAP 42.3 KDE eventually, but it is currently at a testing phase for me right now. Basically I choose not to use an OS unless I have tested it for at least 3 months. When I tried 42.1 I HATED it. 42.2 I really liked it but it was unstable and eventually died at one of the worst possible time. I am buying a new laptop to experiment with 42.3 and Windows 10, but for the time being, 13.2 is what I will be using for some period of time.

#9

As for what I did in the past, I do not remember. I would like to know if someone knows.

Basically running

alsactl init

without sudo access once at boot.

More ideally, I want to install hda-intel audio properly, but right now, the work-around will have to do since I am fully back at work.

#10

What do you mean with “sudo access”? Do you understand where sudo is used for? When you do not have that understanding, the discussion will be very confusing (as it is already IMHO).

suso is tool to change the owing user of a process to be started. Mostly the goal is changing to the Superuser: root.

But all the processes that are started at boot (by systemd) are already owned by user root. Thus putting in a sudo there is complete nonsense.

#11

More than nonsense, the system will refuse to run such a command and throw an error.

TSU

#12

Which the system should do with all nonsense lol!

#13

No, it won’t.

root can use sudo just fine. It’s a no-op though if you don’t specify a different user than root to switch to.

wolfi@amiga:~> su -
Passwort: 
amiga:~ # sudo ls
Desktop  bin  inst-sys
amiga:~ #
#14

Of course that functions as expected, but we are discussing here the use of sudo in a background environment. More precise, one of the scripts run at boot into a certain runlevel. Apart from what you call no-op and we nonsense, which can of course be repeated and nested at will, there is the interactive action of sudo to ask for the password (as you show above).

#15

True. My assumption was the default configuration of sudo which is to enable root permissions, but of course sudo can be configured to apply any User permissions.

TSU

#16

sudo would just as well work in a background script run as root (which is the case for those startup scripts). Of course it would be unnecessary then (unless you want to switch to a different user than root), but it would “work”.

If a password is needed (which isn’t the case if run as root in the first place), it won’t work, yes.
Although that could be “workarounded” via /etc/sudoers… :wink:

#17

Yes, and that’s what I did there.

Again, running sudo as root works (to switch to root), it just does effectively nothing because you are already root.
But it will run the command (as root), and not give an error message.

but of course sudo can be configured to apply any User permissions

Not configured, but you can pass a username on the command line.
I.e. “sudo -u username command”.

And this will work as well when done by root (also in a background service), because root can switch to any user without having to enter a password.