I can’t… this is already suggested by @Yochanan in our private chat but for security reason, i can’t open a GUI during the upgrade via pacman hooks because it is open at the root level. This script runs in background and checks any 10’ . This is only a starter, we can always do better.
Makes kind of sense yes. Although I’m sure there is a way…let me think…
I’m guessing it won’t work to run it with
$ manly sudo -u
sudo, sudoedit — execute a command as another user
-u user, --user=user
Run the command as a user other than the default target user
(usually root). The user may be either a user name or a nu‐
meric user-ID (UID) prefixed with the ‘#’ character (e.g., ‘#0’
for UID 0). When running commands as a UID, many shells re‐
quire that the ‘#’ be escaped with a backslash (‘\’). Some se‐
curity policies may restrict UIDs to those listed in the pass‐
word database. The sudoers policy allows UIDs that are not in
the password database as long as the targetpw option is not
set. Other security policies may not support this.
I know the -u switch but for pass the password i need to open a CLI. I use pkexec instead
There is definitely the need of it for new users, that only click on “apply” in pamac and don’t read the log. We have the Manjaro Notifier to notify for unsupported kernels, pacnews are just as important as we saw with the removal of the extra repo. So for me this actually belong there in the long run. On the short term i think this should be shipped and enabled by default on new installs. Even if it is only in english for now.
We actually discussed it recently here
Congratulations for the script, if looks very nice. My 2-3 cents @Ste74 when i look at the source:
- isn’t 10 minutes a bit too frequently and waste of CPU? At least make it an hour or so?
- meld and yad are not installed by default, i hope you marked them as dependencies (cannot check my mirrors seem not to be updated yet)
- you have a tiny spelling error #Cicla / #Circle
From the screenshot I already have a few suggestion if you don’t mind.
You probably should add safeguards for some of the configuration files, I’m thinking about the
/etc/shadow config file or some similar critical system files that should not be overwritten without knowing the consequences.
Maybe add a group of hard-coded files, some sort of list that could be expanded in the future, that will not be treated the same way, so it is safer for the normal user who usually click “next next next” (maybe remove or change options available).
The “conflict” term is a bit strong to my taste but I guess this is a whole discussion for a point of detail in the end.
So the idea is this should be running always and relies on that sleep loop?
Why not use systemd+timer ?
Also … why does it specifically ignore pacsaves? They can be important too.
More typos also:
# The user has chosen to opening the diff files.
(better would be “The user has chosen to open the diff files”
except … they arent diff files … so its somewhat misleading.
A bit like the next text issue:
Management of configuration conflicts completed.
There arent really conflicts.
Oh, and, it should be mentioned that the
admin:* bit you are using in meld is a function of gvfs … so that would need to be a depend too.
( I would know … because this approach is directly lifted from my fork I shared here )
Thank you, yep i need to increase the time and my english is not my best…
Was my first attempt but yad can be called from a systemd service? Is an admin ( root ) service right ?
Right pacsave can be managed also… and yes my english is bad
First - systemd user units exist … and second - theres nothing saying you cant use
sudo is not equivalent to “super user do” it is more equivalent to “do as” … and that can be any user)
And heres some more food for thought.
Sorry for the tome … it looks bigger than it is because of quotations.
I should clarify again that
pacdiff -s accomplishes this already quite well, which is why I eventually considered the fork unnecessary.
While somewhat less than intuitive … the ‘view’ option of pacdiff indeed works as ‘view and edit’, while
-s is not simply ‘pass sudo’ … its rather
sudoedit … meaning it handles permissions properly and is acting on temporary files and uses sudo afterwards to apply changes.
Use sudo and sudoedit to merge/remove files.
Edit one or more files instead of running a command. In lieu of a path name, the string "sudoedit" is used when consulting the security policy. If the user is autho‐
rized by the policy, the following steps are taken:
1. Temporary copies are made of the files to be edited with the owner set to the invoking user.
2. The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that
order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.
3. If they have been modified, the temporary files are copied back to their original location and the temporary versions are removed.
To help prevent the editing of unauthorized files, the following restrictions are enforced unless explicitly allowed by the security policy:
• Symbolic links may not be edited (version 1.8.15 and higher).
• Symbolic links along the path to be edited are not followed when the parent directory is writable by the invoking user unless that user is root (version 1.8.16 and
• Files located in a directory that is writable by the invoking user may not be edited unless that user is root (version 1.8.16 and higher).
Users are never allowed to edit device special files.
If the specified file does not exist, it will be created. Unlike most commands run by sudo, the editor is run with the invoking user's environment unmodified. If the
temporary file becomes empty after editing, the user will be prompted before it is installed. If, for some reason, sudo is unable to update a file with its edited ver‐
sion, the user will receive a warning and the edited copy will remain in a temporary file.
…meaning … that there is not a reason to make all of these extra functions.
If you need/want to add yad or other graphical notifications and/or buttons then go for it.
pacdiff -s alone will handle all of the pacnew/pacsave and permissions and editing and so on … so long as
DIFFPROG is set to whatever your preferred editor is. If set to meld … then
pacdiff -s will do what this utility does, but better (just without the graphical prompts) … so I humbly suggest you revisit this with these things in mind …
yad = ok
circumventing pacdiff for no good reason = less ok
Use AI to dumb it down even more. The future.
I try to run this function after a big update, and handle the pacnew files then.
But at the moment, I don’t understand how to exclude path’s out of a find command.
sudo find / -iname '*.pacnew' -type f -print -not -path '/run/*'
# todo try to exclude path's
# sudo find / -iname '*.pacnew' -type f -not -path '/proc/*' -not -path '/run/*' -not -path '/timeshift/*' -not -path '/var/log/*' -not -path '.config/VSCodium/' -not -path '/timeshift/*' -print
find / -type f -name "*.pacnew" ! -path "/proc/*" ! -path "/run/*" 2>/dev/null
(I cant seem to force find to not look at /run/user/1000/ either)
Ah here we go:
sudo find / \( -path /proc -o -path /run -o -path /tmp \) -prune -o -type f -regex ".*\.pac\(new\|save\|orig\)" -print
and a bit smaller with regex:
sudo find / -regex /"\(proc\|tmp\|run\)" -prune -o -type f -regex ".*\.pac\(new\|save\|orig\)" -print
(added pacsave and pacorig too)
yes. its the tool for the job, but for some reason people avoid it.
If you just want to list them wouldn’t
pacdiff -o be a lot easier?
That’s what Stefano is using. The find function question seems to be another project.
Sure, it would still just be great to know a universal method where I can use on different stuff aswell.
If you’re using pacdiff, then you’ve also got paclog installed too:
paclog --after=2023-07-01|paclog --warnings
[2023-07-29T02:20:59-0400] [ALPM] warning: directory permissions differ on /etc/credstore/
filesystem: 0 package: 700
[2023-07-29T02:20:59-0400] [ALPM] warning: directory permissions differ on /etc/credstore.encrypted/
filesystem: 0 package: 700
[2023-08-07T11:42:19-0400] [ALPM-SCRIPTLET] error: No package owns /usr/lib/perl5/5.36
[2023-08-08T22:40:27-0400] [ALPM] warning: directory permissions differ on /boot/
filesystem: 700 package: 755
[2023-08-11T12:14:07-0400] [ALPM] warning: /etc/ssh/sshd_config installed as /etc/ssh/sshd_config.pacnew
[2023-08-23T20:10:05-0400] [ALPM] warning: /etc/pacman.d/mirrorlist installed as /etc/pacman.d/mirrorlist.pacnew
Well manjaro-pacnew-checker now is at 0.2.0 version and i have correct my bad english, pacnew and pacsave are listed and i switched to a systemd service. Now any 3 hours the check start.
I’m thinking of adding the service to some program like pacman or manjaro-system to make it reach even the old installations. Toughts ?
Personally, I wouldn’t do that. Have it running as a
pacman hook after updating, yes — that’s where it matters — but I for one wouldn’t want to have it running as a timer.
If you know of a way to accomplish that, that would be great.
Exists already for existing tools …