sudo: please make it optional

[vitaly-zdanevich]

Also because I want to package it for Gentoo Linux - so it already will be installed with root.

[ivan-hc]

@Samueru-sama I need your help here, I know you use "doas"

[ivan-hc]

While using "AM", this is the function that made it work with "sudo"

function _am() {
	AMCLI="am"
	AMCLIPATH="$AMCLI"
	SUDOCOMMAND="sudo"
	COMPLETIONPATH="/etc/bash_completion.d"
	COMPLETIONFILE="am-completion.sh"
	APPSPATH="/opt"
	AMPATH="$APPSPATH/$AMCLI"
	_create_cache_dir
	mkdir -p "$AMPATH"/modules
}

https://github.com/ivan-hc/AM/blob/4d30b36ff2a17adde3f8f593f1236b195ff1a3ab/APP-MANAGER#L54C1-L64C2

[Samueru-sama]

I'm a doas user, however I use AppMan instead of AM which doesn't need elevated privileges. A while ago I did some changes that makes AM depend less on sudo, but if I'm not mistaken it still isn't ready.

@vitaly-zdanevich #827

Once that is merged to dev, please enable the developer mode and update AM and let me know if you still have issues without sudo.

[ivan-hc]

@vitaly-zdanevich do am --devmode-enable and then, update with am -s

[ivan-hc]

@Samueru-sama discord

[Samueru-sama]

Btw @ivan-hc the same if command -v sudo else command -v doas has to be done in the INSTALL script, I will do it tomorrow, but if you want to do it now do it.

@vitaly-zdanevich Let us know if AM works now with doas.

[ivan-hc]

Btw @ivan-hc the same if command -v sudo else command -v doas has to be done in the INSTALL script, I will do it tomorrow, but if you want to do it now do it.

done fa2dc8b and 249a3c8

also updated the README about one hour ago 839ad9f

in my use case also the installer worked like a charm on the Fedora VM.

[vitaly-zdanevich]

Oh my, I do not know what doas is...

[vitaly-zdanevich]

Looks like unnecessary dependency for installing :(

[vitaly-zdanevich]

When user install from root - is it possible to expect that?

[Samueru-sama]

Looks like unnecessary dependency for installing :(

You are telling me you don't have sudo or doas in your system?!

[vitaly-zdanevich]

Yes, for what? My root terminal is always running in a dedicated workspace.

[vitaly-zdanevich]

And again - I plan to write the ebuild for it - so it will be installed from root.

[ivan-hc]

I don't know why all this remembers me Kali Linux

[Samueru-sama]

Yes, for what? My root terminal is always running in a dedicated workspace.

What are you doing that you need a root terminal constantly open?

You might wanna read this

The only times I need to doas is when installing pacman packages, and I have a doas rule that lets me run pacman -Syu without needing to enter the password, for the appimages and portable apps I use AppMan instead of AM as well.

I don't think it is a good idea at all to have a root terminal open, like the fact that you have it open tells me that you use it constantly which is worrisome to say the least.

[ivan-hc]

I don't think it is a good idea at all to have a root terminal open, like the fact that you have it open tells me that you use it constantly which is worrisome to say the least.

this is what I mean. You made me think that you are doing everything as root, also net browsing, like in Kali.

I only see risks here.

[vitaly-zdanevich]

I don't think it is a good idea at all to have a root terminal open, like the fact that you have it open tells me that you use it constantly which is worrisome to say the least.

I have a few terminals, I do not use the root terminal always. Root terminal is autostarted on the specific display.

[vitaly-zdanevich]

this is what I mean. You made me think that you are doing everything as root, also net browsing, like in Kali.

No, mostly I use regular user of course. I need root terminal to write and test my ebuilds, for example.

[ivan-hc]

I understand

@Samueru-sama in the function you added, can be added an if case to determine if the user is root?

I think that other than sudo and doas

if [ "$currentuser" = "root" ]; then
      SUDOCAMMAND=""

or something.

[ivan-hc]

just tested with a root account in Debian, on VirtualBox, both "AM" installation and usage, and all works as expected.

its enough to add this line to APP-MANAGER and AM-INSTALLER

elif [ "$currentuser" = root ]; then
		SUDOCOMMAND=""
	else

as I said before

[ivan-hc]

uhm... something is gone wrong, I've tried by removing both "sudo" and "doas" as options and the installer have not recognized that I'm root, so I had an exit 1

[ivan-hc]

just noticed that $currentuser is not in AM-INSTALLER

[ivan-hc]

this is the one that worked

if [ "$(id -u)" = 0 ]; then

[ivan-hc]

this function did the trick

	if command -v sudo >/dev/null 2>&1; then
		SUDOCOMMAND="sudo"
	elif command -v doas >/dev/null 2>&1; then
		SUDOCOMMAND="doas"
	elif [ "$(id -u)" = 0 ]; then
		SUDOCOMMAND=""
	else
		echo "ERROR: you need to be \"root\" to use \"AM\""
		exit 1
	fi

note, I've tested also only the one to use AM as root, so without sudo and doas as options

[ivan-hc]

maybe I should put "root" as first choice

	if [ "$(id -u)" = 0 ]; then
		SUDOCOMMAND=""
	elif command -v sudo >/dev/null 2>&1; then
		SUDOCOMMAND="sudo"
	elif command -v doas >/dev/null 2>&1; then
		SUDOCOMMAND="doas"
	else
		echo "ERROR: you need to be \"root\" to use \"AM\""
		exit 1
	fi

[ivan-hc]

worked

[ivan-hc]

if you need to test the AM-INSTALLER, it will download "AM" from "main", while the changed version is in "dev"

[ivan-hc]

but other non-main-admins can't still use AM, its necessary to be the one that have installed AM

[ivan-hc]

the rule is still the same: the one that installs AM is the one that can do anything in /opt/am

[ivan-hc]

I prefer not to change what has already widelly used. AppMan is the way to go for unprivileged users.

About to made "sudo" optiona, I think that this commit should fix this issue 7cb3cbc

[vitaly-zdanevich]

Thanks! Will check later.

[ivan-hc]

Thanks! Will check later.

the change is still in "dev", you should run am --devmode-enable to use it

[ivan-hc]

@vitaly-zdanevich change of program!

As you said in the first message

Also because I want to package it for Gentoo Linux - so it already will be installed with root.

since the reason because the issue was opened was the packaging of AM for Gentoo, I think that "sudo" or "doas" will keep be dependences for "AM" itself, after it is installed.

A package for repositories being executed as ROOT, needs to use the INSTALL script from the repository.

That said, usage of "AM" and its installation via AM-INSTALLER have non sense while the program is installed via system package manager.

Changes done in the previous pull request will not be applied.

As I have already said at #840, and according to what we said at #830 , this is the guide to package AM for other distributions. I'll repaste the comment

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

What you need to know before you start packaging "AM" for other distros

About changes in this project directly, "AM" is a third-party app released under GPL3 and is provided as is.

Being it a third party app, I must write it to follow the LSB, so no way I can apply the changes you asked by default.

All I can say to you is how to edit your own copy to made it work the way you want.

Changes in "INSTALL"

The "INSTALL" script is the one that must be executed to install AM and its modules and components

1. change /opt/am to /usr/share/am (for data of applications, "APP-MANAGER" included)
2. symlink the script /usr/share/am/APP-MANAGER to /usr/bin/am or /bin/am
3. remove the following lines to prevent "AM" being removed using "am -R am" or other actions

	# CREATE THE SCRIPT NEEDED TO UNINSTALL "AM"
	printf '#!/bin/sh\n\nset -e\n' > /opt/am/remove
	printf '\n%s\n' 'if [ "$(id -u)" -ne 0 ]; then echo "Permission denied"; exit 1; fi' >> /opt/am/remove
	printf '%s\n' 'rm -f /usr/local/bin/am /etc/bash_completion.d/am-completion.sh' >> /opt/am/remove
	printf '%s\n' 'rm -R -f /opt/am' >> /opt/am/remove
	chmod a+x /opt/am/remove || exit 1

since you need to run it as root, you already know how to run the script without "sudo" or "doas"

NOTE: if you don't care if AM is installed in /usr/share and you want to keep AM installed in /opt, ignore points 1 and 2.

Changes in APP-MANAGER (do this into a post-installation script)

1. To prevent that AM updates itself and the modules, if they are already packaged. You can use sed to disable/comment the following two lines in APP-MANAGER

AM/APP-MANAGER

Line 806 in dd5cac6

_sync_modules

AM/APP-MANAGER

Line 807 in dd5cac6

_sync_amcli

2. the variable $AMPATH means /opt/am, change the value of this variable /usr/share/am, or maybe try to move it to a RW directory, for example ~/.cache. You can use sed for this

AM/APP-MANAGER

Line 68 in dd5cac6

AMPATH="$APPSPATH/$AMCLI"

all is done in this directory are updating of lists and keywords, or running installation scripts or data for the apps, like versions and type.

NOTE: again, if you don't care if AM is installed in /usr/share and you want to keep AM installed in /opt, ignore the point 2.

---

That said, I close this as not planned. Thank you for your interest. I worked a lot on this issue before I figure out that all this was to package AM as a package for Gentoo, or for any other distro.

"root" only usage of "AM" is not something for what this tool was designed.

If you have other questions, I'm here.