Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
On 9/8/19 6:27 PM, Xianwen Chen (陈贤文) via arch-general wrote: > For example, > > $ sudo pacrepairfile --uid --gid --mode --mtime > /usr/lib/tmpfiles.d/colord.conf > > outputs > > /usr/lib/tmpfiles.d/colord.conf: set uid to 0 > /usr/lib/tmpfiles.d/colord.conf: set gid to 0 > warning: /usr/lib/tmpfiles.d/colord.conf: unable to set permissions > (Operation not supported) > /usr/lib/tmpfiles.d/colord.conf: set modification time to 111829 > > What happened with pacrepairfile? Ah, now I remember that https://github.com/andrewgregory/pacutils/issues/32 is a thing. :) The --mode option has some issues. Perhaps try asking for a status update there? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
Dear Eli, Thank you. I wrote a regulation expression, which extracts file name and path from the output of paccheck: $ sudo paccheck --file-properties --quiet | grep -Po "(?<=\').*(?=\')" | sudo pacrepairfile --uid --gid --mode --mtime However, somehow pacrepairfile was not working. For example, $ sudo pacrepairfile --uid --gid --mode --mtime /usr/lib/tmpfiles.d/colord.conf outputs /usr/lib/tmpfiles.d/colord.conf: set uid to 0 /usr/lib/tmpfiles.d/colord.conf: set gid to 0 warning: /usr/lib/tmpfiles.d/colord.conf: unable to set permissions (Operation not supported) /usr/lib/tmpfiles.d/colord.conf: set modification time to 111829 What happened with pacrepairfile? Yours sincerely, Xianwen On 08/09/2019 22.53, Eli Schwartz via arch-general wrote: On 9/8/19 4:40 PM, Xianwen Chen (陈贤文) via arch-general wrote: Dear Eli, Thank you! Is there a way to ask paccheck to list only files that need to be fixed? For example, if I run sudo paccheck --file-properties --quiet I get list of files with package information and error information, such as screen: '/usr/lib/tmpfiles.d/screen.conf' permission mismatch (expected 644) Or maybe I need to write a regular expression to extract file name and path from such an output myself? No, paccheck does not have an option to do this. You could try submitting a feature request for it. :) You can extract everything between the '' though, which I think should handle any filenames since packaged filenames can contain spaces or single quotes but not newlines, and the paccheck output doesn't contain any more single quotes after the quoted filename.
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
On 9/8/19 4:40 PM, Xianwen Chen (陈贤文) via arch-general wrote: > Dear Eli, > > Thank you! > > Is there a way to ask paccheck to list only files that need to be fixed? > > For example, if I run > > sudo paccheck --file-properties --quiet > > I get list of files with package information and error information, such as > > screen: '/usr/lib/tmpfiles.d/screen.conf' permission mismatch > (expected 644) > > Or maybe I need to write a regular expression to extract file name and > path from such an output myself? No, paccheck does not have an option to do this. You could try submitting a feature request for it. :) You can extract everything between the '' though, which I think should handle any filenames since packaged filenames can contain spaces or single quotes but not newlines, and the paccheck output doesn't contain any more single quotes after the quoted filename. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
Dear Eli, Thank you! Is there a way to ask paccheck to list only files that need to be fixed? For example, if I run sudo paccheck --file-properties --quiet I get list of files with package information and error information, such as screen: '/usr/lib/tmpfiles.d/screen.conf' permission mismatch (expected 644) Or maybe I need to write a regular expression to extract file name and path from such an output myself? Yours sincerely, Xianwen On 08/09/2019 19.14, Eli Schwartz via arch-general wrote: On 9/8/19 8:21 AM, Xianwen Chen (陈贤文) via arch-general wrote: Dear Ralph and Eli, Thank you. As Ralph suspected, there are quite many files on my system that had wrong permissions or GID's. Is there a way to automatically correct all the permissions and GID's? Once more from the pacutils package, comes the "pacrepairfile" command. Given a list of files and the (separate, additive) arguments --uid --gid --mode --mtime you can reset the file to what its mtree data specified. If the file size/contents differ, you will have to do a bit of manual work yourself, or reinstall the package.
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
Dear Ralph,
Great! Thank you very much for the tips!
Yours sincerely,
Xianwen
On 08/09/2019 15.11, Ralph Corderoy wrote:
Dear Xianwen,
there are quite many files on my system that had wrong permissions or
GID's.
Perhaps there's been an errant recursive chmod or chgrp in the past by
root.
Is there a way to automatically correct all the permissions and GID's?
Others like Eli might know an mtree-specific way, but if there's a
common feature, like lots of files under /usr/bin that are group xianwen
instead of root, then find(1) could be used to first list what it would
change, allowing the list to be checked by eye, and then correct.
Something like
find -xdev /usr/bin -group xianwen -ls
find -xdev /usr/bin -group xianwen -exec chgrp root {} +
https://mywiki.wooledge.org/UsingFind might help if you're not familiar
with find(1). It has -user and -perm too.
Or you could try and use the output of paccheck(1) to produce a script
to execute, again after checking it by eye.
sudo -i paccheck --quiet --file-properties |
awk '
/ permission mismatch / {
print "chmod 0" substr($6, 1, length($6)-1), $2
}
'
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
On 9/8/19 8:21 AM, Xianwen Chen (陈贤文) via arch-general wrote: > Dear Ralph and Eli, > > Thank you. > > As Ralph suspected, there are quite many files on my system that had > wrong permissions or GID's. > > Is there a way to automatically correct all the permissions and GID's? Once more from the pacutils package, comes the "pacrepairfile" command. Given a list of files and the (separate, additive) arguments --uid --gid --mode --mtime you can reset the file to what its mtree data specified. If the file size/contents differ, you will have to do a bit of manual work yourself, or reinstall the package. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
On 9/8/19 7:59 AM, Ralph Corderoy wrote: > $ sudo -i paccheck --file-properties atop > atop: '/var/log/atop/dummy_after' permission mismatch (expected 644) > atop: '/var/log/atop/dummy_after' modification time mismatch > (expected 2019-02-06 20:40:14) > atop: '/var/log/atop/dummy_before' permission mismatch > (expected 644) > atop: '/var/log/atop/dummy_before' modification time mismatch > (expected 2019-02-06 20:40:14) > $ > > The modification-time mismatch above suggests the package's mtree needs > to allow for the mtime to vary. Well, it would depend on the file, these ones seem to be logfiles. I wonder why they exist in the package at all, if that is the case? > As an installation ages, it seems the number of disagreements between it > and the packages grows. What can be done to try and centrally fix some > of them for all installations? > > I expect sometimes a package or upstream changed a file's properties in > the packaging, but neglected to alter what was already in place on the > upgrade to that package version. I'd have thought if research shows it > is the package, or upstream, that changed the properties then it's not > too late and the package can change to check and fix those on upgrade. Well, no, pacman will delete the old version and install the new version every time you update or reinstall a package, and in the process it totally ignores the on-disk modification time, permission bits, and previous contents. So it doesn't matter how old your installation is, "disagreements" should remain a constant defined by the package from which it comes. It will be just as much in disagreement the day you install Arch complete with your list of favorite packages, as it will be 25 years later after you've faithfully pacman -Syu'ed once a day/week. The exception is directories, for which pacman explicitly logs a warning that "permissions differ" and expects the user to research why that might be so. Directories are a bit unusual in that multiple packages can own them, after all, so different packages might "legitimately" have different ideas about what permissions a directory should have. These need to be resolved on a higher level than simply "pick the first one pacman extracts". Sometimes, those directories are changed in the one package that owns them. For example, /etc/NetworkManager/system-connections/ used to be readable by any user, which allowed users to see which filenames were available as configured networkmanager connections. Now the package changed to install it as 700, and you cannot use ls in there anymore (but you can still use nmtui/nmcli/nm-applet to view absolutely anything by default). In this case you might well be advised to change the permissions yourself, OTOH maybe you want to leave it as is for personal reasons? > Do the packaging tools provide a means of checking that the proposed > mtree differs for existing items to the previous one? That would help > packagers realise upstream have made a change. Well, no. How would you even be able to determine this in the first place? Let's say Joe User's files differ from the package -- mine don't, what do I as a packager do? What about /usr/lib/modules/$(uname -r)/modules.* which are packaged in pristine condition, but then updated by depmod? Those are supposed to not match. What about backup files, which are definitively supposed to not match the packaged version? pacman -Qkk reports these by default: backup file: pacman-git: /etc/makepkg.conf (Modification time mismatch) backup file: pacman-git: /etc/makepkg.conf (Size mismatch) backup file: pacman-git: /etc/pacman.conf (Modification time mismatch) backup file: pacman-git: /etc/pacman.conf (Size mismatch) warning: pacman-git: /usr/share/locale/de/LC_MESSAGES/pacman.mo (UID mismatch) warning: pacman-git: /usr/share/locale/de/LC_MESSAGES/pacman.mo (GID mismatch) warning: pacman-git: /usr/share/locale/de/LC_MESSAGES/pacman.mo (Modification time mismatch) warning: pacman-git: /usr/share/locale/de/LC_MESSAGES/pacman.mo (Size mismatch) yes, I have strange locale files, this is because I tested someone's patch to add localized strings to pacman-conf and that involved cp'ing a .mo file to /usr/share. You'll notice that the locales are a "warning:" (bold yellow) while the backup file is "backup file:" (bold white) paccheck doesn't show backup files, as it has more fine-grained controls and should be toggled via paccheck --file-properties --backup if you really want to check them. > Blindly altering the filesystem to match mtree might be the wrong thing, > disguising a real problem. By getting rid of the noise caused by > package upgrades, real faults can start to be seen. Well, sure, that is why it is just a check by default. :) But permissions are "generally" okay. And modification time is nearly meaningle
[arch-general] Recommend new package : Postfix and MTA-STS (RFC8461)
Topic: Email Suggest: New package for officia repo [2] MTA-STS is taking off and the major email providers are supporting it. Details are described in RFC8461 [1] from Sep 2018. As of now it has support by Google (gmail), yahoo, comcast, hotmail and others. MTA-STS is a new standard that aims to improve the security of SMTP by enabling domain names to opt into strict transport layer security mode that requires authentication (with valid public certificates) and encryption (TLS). There are 2 components to this (a) Sending: Making email server advertise mta-sts (b) Receivng: Postfix needs policy daemon (a) is pretty straightforward to set up, (b) requires a daemon to support the policy for incoming mail. It would be pretty awesome if someone would think about an offocial postfix-mta-sts-resolve package [2]. Postfix can use this daemon - see some discussion on this here [5] where Wietse got involved as well. There is an AUR package but it is quite out of date and I think this would actually be better to be in the official repos if someone was interested in taking it on. Probably as an optional package for postfix This is important for any business use and of course for anyone running their own mail server on Arch. Over time it is likely that any server which does not turn this on at least for sending may find their email being disadvantaged. There are several places where this is discussed in more detail - here's a couple for convenience [3]. Thanks, gene [1] https://tools.ietf.org/html/rfc8461 [2] https://github.com/Snawoot/postfix-mta-sts-resolver [3] https://weekly-geekly.github.io/articles/424961/index.html https://www.hardenize.com/blog/mta-sts https://www.uriports.com/blog/mta-sts-explained/ https://starttls-everywhere.org/ [5] http://postfix.1071664.n5.nabble.com/MTA-STS-when-td95086.html
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
Dear Xianwen,
> there are quite many files on my system that had wrong permissions or
> GID's.
Perhaps there's been an errant recursive chmod or chgrp in the past by
root.
> Is there a way to automatically correct all the permissions and GID's?
Others like Eli might know an mtree-specific way, but if there's a
common feature, like lots of files under /usr/bin that are group xianwen
instead of root, then find(1) could be used to first list what it would
change, allowing the list to be checked by eye, and then correct.
Something like
find -xdev /usr/bin -group xianwen -ls
find -xdev /usr/bin -group xianwen -exec chgrp root {} +
https://mywiki.wooledge.org/UsingFind might help if you're not familiar
with find(1). It has -user and -perm too.
Or you could try and use the output of paccheck(1) to produce a script
to execute, again after checking it by eye.
sudo -i paccheck --quiet --file-properties |
awk '
/ permission mismatch / {
print "chmod 0" substr($6, 1, length($6)-1), $2
}
'
--
Cheers, Ralph.
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
Dear Ralph and Eli, Thank you. As Ralph suspected, there are quite many files on my system that had wrong permissions or GID's. Is there a way to automatically correct all the permissions and GID's? Yours sincerely, Xianwen On 08/09/2019 11.28, Eli Schwartz via arch-general wrote: On 9/8/19 5:20 AM, Ralph Corderoy wrote: Dear Xianwen, After searching on-line, it seemed that similar problems were reported by other users of systemd. The fix is to set owner of / as root.root. I tried the solution and it worked! I'm glad you fixed it. / not being root:root is strange. You may wish to sudo -i pacman -Qqkk to check for other odd permissions, etc., in case they too cause problems later. Note, it seems normal for some packages to cause grumbles from the above command. If a package is listed, I then do sudo -i pacman -Qkk atop to see more detail of the problem. Though unfortunately not enough detail, i.e. warning: atop: /var/log/atop/dummy_after (Permissions mismatch) doesn't tell me what they should be. One has to grovel around in the mtree file for that. $ zcat /var/lib/pacman/local/atop-*/mtree | > grep '^./var/log/atop/dummy_after ' | > fmt ./var/log/atop/dummy_after time=1549485614.0 size=0 md5digest=d41d8cd98f00b204e9800998ecf8427e sha256digest=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 $ This entry doesn't have a ‘mode=...’ stating the desired permissions. mtree(5) doesn't say so, but I think it defaults to 0644 for files based on the other mode-less entries in that mtree file that don't cause pacman to complain. Not every error means the file on disk must be changed, perhaps it's a packaging problem, but it can be a useful aid. pacman -S pacutils && paccheck --file-properties
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
Hi Eli, > > warning: atop: /var/log/atop/dummy_after (Permissions mismatch) > ... > > Not every error means the file on disk must be changed, perhaps it's > > a packaging problem > > pacman -S pacutils && paccheck --file-properties Thanks. $ sudo -i paccheck --file-properties atop atop: '/var/log/atop/dummy_after' permission mismatch (expected 644) atop: '/var/log/atop/dummy_after' modification time mismatch (expected 2019-02-06 20:40:14) atop: '/var/log/atop/dummy_before' permission mismatch (expected 644) atop: '/var/log/atop/dummy_before' modification time mismatch (expected 2019-02-06 20:40:14) $ The modification-time mismatch above suggests the package's mtree needs to allow for the mtime to vary. As an installation ages, it seems the number of disagreements between it and the packages grows. What can be done to try and centrally fix some of them for all installations? I expect sometimes a package or upstream changed a file's properties in the packaging, but neglected to alter what was already in place on the upgrade to that package version. I'd have thought if research shows it is the package, or upstream, that changed the properties then it's not too late and the package can change to check and fix those on upgrade. Do the packaging tools provide a means of checking that the proposed mtree differs for existing items to the previous one? That would help packagers realise upstream have made a change. Blindly altering the filesystem to match mtree might be the wrong thing, disguising a real problem. By getting rid of the noise caused by package upgrades, real faults can start to be seen. (BTW, can you quote just what's needed, following the Code of Conduct.) -- Cheers, Ralph.
[arch-general] Nvidia HDMI Audio as Kernel Parameter
Hello all, I am using plain linux kernel 5.2.13 with proprietary nvidia driver 435.21 on my Nvidia Optimus (UHD 630 + 1050 Ti) notebook. Nothing fancy here and everything is up to date but in order to utilize HDMI audio over Nvidia card, I have to use this fix: https://wiki.archlinux.org/index.php/NVIDIA/Troubleshooting#No_audio_over_HDMI This fix works. However either I need to manually execute those commands every time I boot (this causes X to restart) or I need to make a systemd service out of them and enable it to work on every boot (I got the idea from Nvidia forums). But systemd service sometimes makes X fail to start. So I was wondering if there is any kernel parameter with the same effect which I can apply BEFORE or DURING loading nvidia modules by simply adding it to boot options. Thanks in advance -- Ali Emre Gülcü
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
On 9/8/19 5:20 AM, Ralph Corderoy wrote: > Dear Xianwen, > >> After searching on-line, it seemed that similar problems were reported >> by other users of systemd. The fix is to set owner of / as root.root. >> I tried the solution and it worked! > > I'm glad you fixed it. / not being root:root is strange. You may wish > to > > sudo -i pacman -Qqkk > > to check for other odd permissions, etc., in case they too cause > problems later. Note, it seems normal for some packages to cause > grumbles from the above command. If a package is listed, I then do > > sudo -i pacman -Qkk atop > > to see more detail of the problem. Though unfortunately not enough > detail, i.e. > > warning: atop: /var/log/atop/dummy_after (Permissions mismatch) > > doesn't tell me what they should be. One has to grovel around in the > mtree file for that. > > $ zcat /var/lib/pacman/local/atop-*/mtree | > > grep '^./var/log/atop/dummy_after ' | > > fmt > ./var/log/atop/dummy_after time=1549485614.0 > size=0 md5digest=d41d8cd98f00b204e9800998ecf8427e > > sha256digest=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 > $ > > This entry doesn't have a ‘mode=...’ stating the desired permissions. > mtree(5) doesn't say so, but I think it defaults to 0644 for files based > on the other mode-less entries in that mtree file that don't cause > pacman to complain. > > Not every error means the file on disk must be changed, perhaps it's a > packaging problem, but it can be a useful aid. pacman -S pacutils && paccheck --file-properties -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
Dear Xianwen, > After searching on-line, it seemed that similar problems were reported > by other users of systemd. The fix is to set owner of / as root.root. > I tried the solution and it worked! I'm glad you fixed it. / not being root:root is strange. You may wish to sudo -i pacman -Qqkk to check for other odd permissions, etc., in case they too cause problems later. Note, it seems normal for some packages to cause grumbles from the above command. If a package is listed, I then do sudo -i pacman -Qkk atop to see more detail of the problem. Though unfortunately not enough detail, i.e. warning: atop: /var/log/atop/dummy_after (Permissions mismatch) doesn't tell me what they should be. One has to grovel around in the mtree file for that. $ zcat /var/lib/pacman/local/atop-*/mtree | > grep '^./var/log/atop/dummy_after ' | > fmt ./var/log/atop/dummy_after time=1549485614.0 size=0 md5digest=d41d8cd98f00b204e9800998ecf8427e sha256digest=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 $ This entry doesn't have a ‘mode=...’ stating the desired permissions. mtree(5) doesn't say so, but I think it defaults to 0644 for files based on the other mode-less entries in that mtree file that don't cause pacman to complain. Not every error means the file on disk must be changed, perhaps it's a packaging problem, but it can be a useful aid. -- Cheers, Ralph.
