Re: [arch-general] Missing sys_siglist declaration
On Thu, 1 Oct 2020 15:30:44 -0400, Eli Schwartz via arch-general wrote: > Indeed it does, you can report a documentation bug here: > https://www.kernel.org/doc/man-pages/reporting_bugs.html Done. Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] Missing sys_siglist declaration
On Thu, 1 Oct 2020 13:57:09 -0400, Eli Schwartz via arch-general wrote: > From the glibc 2.32 release notes: > > Deprecated and removed features, and other changes affecting compatibility: > [...] > * The deprecated arrays sys_siglist, _sys_siglist, and sys_sigabbrev > are no longer available to newly linked binaries, and their declarations > have been removed from . They are exported solely as > compatibility symbols to support old binaries. All programs should use > strsignal instead. > > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b1ccfc061feee9ce616444ded8e1cd5acf9fa97f Thanks! I'll look into that. As I said, the strsignal(3) man page still refers to sys_siglist, so that would need updating. Cheerio, Hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
[arch-general] Missing sys_siglist declaration
Hi, on an arch machine updated yesterday, my XEmacs does not build because the 'sys_siglist' declaration is gone from , where the strsignal(3) man page says it should be. Searching the usual suspects didn't bring up anything. What did I miss? Cheerio, Hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] NFS "updates"?
On Wed, 29 Apr 2020 14:40:26 +0100, Leonidas Spyropoulos via arch-general wrote: > Might worth reaching out to linux-...@vger.kernel.org mailing list instead > of Archlinux as this is upstream default behaviour. Personally, I have no standing here nor there, so I won't follow your suggestion. The linux-nfs@ members would probably reply that downstream distributions are free to ship nfs over udp enabled kernels if they choose so... Response to the proposal of deprecating UDP transport <https://www.spinics.net/lists/linux-nfs/msg74889.html> was positive, as much as there was. Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] NFS "updates"?
On Mon, 27 Apr 2020 19:25:59 +0100, Leonidas Spyropoulos via arch-general wrote: > On 27/04/20, Hauke Fath wrote: >> Re-reading, this is an Arch decision -- what is the rationale? Can >> anybody point me to a related discussion? > > It's not, it just defaults to "Y", see patch in > https://github.com/archlinux/linux/commit/b24ee6c64ca785739b3ef8d95fd6becaad1bde39 Defaulting to "disabled" strikes me as heavy-handed. From my experience, of running a few dozen nfs clients over more than fifteen years, at network speeds from 100 MBit clients / 1 GBit server to 1 GBit clients / 10 GBit server, the real-world relevance of ip fragment counter overruns is debatable. From a general background of transmission errors [1], the effect does not seem to stand out. FTR, we are running nfs through a filtering router, and found udp transport to be much more robust in the face of router outages. So, to summarize: The kernel nfs developers have deprecated nfs over udp in late 2019, AFAICS without much debate, and without any announcement outside the developers' mailing-list [2]. So far, so unspectacular. The interesting question is whether Linux distributions (Arch) should import this kernel change uncritically, and dump it on their unsuspecting users, without so much as a warning. Given nfsv3 defaults to tcp, the "protect the innocent / think of the children" argument does not fly: When the admin wants to use nfs over udp (whether she chooses, or has to), she has to actively configure the mount, and take responsibility. In this light, disabling nfs over udp in the kernel seems patronizing to professional admins. My question is: Where should I take the issue for further discussion? Is this mailing-list the right place? A forum group? Should I file a bug report? Cheerio, Hauke [1] <http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf> [2] <https://www.spinics.net/lists/linux-nfs/msg75432.html> -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] NFS "updates"?
On Mon, 27 Apr 2020 19:25:59 +0100, Leonidas Spyropoulos via arch-general wrote: > On 27/04/20, Hauke Fath wrote: >> Re-reading, this is an Arch decision -- what is the rationale? Can >> anybody point me to a related discussion? > > It's not, it just defaults to "Y", -- which requires building your own kernel to change, right? > see patch in > https://github.com/archlinux/linux/commit/b24ee6c64ca785739b3ef8d95fd6becaad1bde39 > > There's also a bit of explanation if it's useful Yes, it is - actually, nfs(5) has a much longer explanation, as well as a viable workaround: Shorten the udp fragment reassembly timeout on fast networks. On Mon, 27 Apr 2020 20:12:17 +0200, Markus Schaaf via arch-general wrote: >> It's a kernel configuration which is introduced with 5.6 kernel. In my >> CONFIG_NFS_DISABLE_UDP_SUPPORT=y > > Wow! I'd say udp is used a lot with nfsvers=3. That will break many nfs3 > deployments. This. I (and my users) certainly would appreciate if the decision could be reconsidered. Cheerio, Hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] NFS "updates"?
On Mon, 27 Apr 2020 19:00:32 +0100, Leonidas Spyropoulos via arch-general wrote: > $ zcat /proc/config.gz | grep NFS_DISABLE > CONFIG_NFS_DISABLE_UDP_SUPPORT=y > > The change happened with commit > <https://git.archlinux.org/svntogit/packages.git/commit/trunk/config?h=packages/linux=3734fe98a51ca7e776052cdabc80be9885b7d40d> Re-reading, this is an Arch decision -- what is the rationale? Can anybody point me to a related discussion? And why does the kernel end up talking about nfsv4, as if it hit <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6da1a034362f86e157e251e65394f0b6570e3e3a>? Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] NFS "updates"?
On Mon, 27 Apr 2020 19:00:32 +0100, Leonidas Spyropoulos via arch-general wrote: Thanks for the note! > It's a kernel configuration which is introduced with 5.6 kernel. In my > kernel which is 5.6.7-arch1-1 > > $ zcat /proc/config.gz | grep NFS_DISABLE > CONFIG_NFS_DISABLE_UDP_SUPPORT=y Meaning this is an upstream change? Might have been worth an entry on www.archlinux.org/news/... So I guess the short-term fix is to switch to an LTS kernel, and mid-term I will have to get into building my own kernels? Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] NFS "updates"?
On Mon, 27 Apr 2020 19:19:21 +0200, Hauke Fath wrote: > I'll give some of the configuration. FTR, the borken system's kernel is Linux version 5.6.7-arch1-1 (linux@archlinux) (gcc version 9.3.0 (Arch Linux 9.3.0-1)) #1 SMP PREEMPT Thu, 23 Apr 2020 09:13:56 + while the working system has Linux version 5.5.8-arch1-1 (linux@archlinux) (gcc version 9.2.1 20200130 (Arch Linux 9.2.1+20200130-2)) #1 SMP PREEMPT Fri, 06 Mar 2020 00:57:33 + Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] NFS "updates"?
On Mon, 27 Apr 2020 17:23:39 +0200, Markus Schaaf via arch-general wrote: > Am 27.04.20 um 16:51 schrieb Hauke Fath: > >> NFSV4: Unsupported transport protocol udp > > Have you tried vers=3 in mount options? Thanks for the reply. I'll give some of the configuration. (1) autofs config is distributed through nis: % grep '^[/]' /etc/automount/auto.master /home auto.home -udp,nfsvers=3,resvport,nolock,noacl,grpid,retrans=5,rsize=16384,wsize=16384,rw,hard,intr /misc auto.misc -udp,nfsvers=3,resvport,grpid,local_lock=none,retrans=5,rw,hard,intr % (2) The client autofs setup: % grep -v '^#' /etc/autofs/autofs.conf [ autofs ] timeout = 300 browse_mode = no [ amd ] dismount_interval = 300 % This setup has worked for years, and continues to work after rolling back to the 2020-03-09 state. There is no nfsv4 anywhere in sight: The server setup disables it, and wherever I can specify nfsv3 on the client, I have. From the journal: [...] Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de automount[567]: attempting to mount entry /home/XXX Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: Registered named UNIX socket transport module. Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: Registered udp transport module. Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: Registered tcp transport module. Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: Registered tcp NFSv4.1 backchannel transport module. Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: FS-Cache: Netfs 'nfs' registered for caching Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: *** VALIDATE nfs *** Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: *** VALIDATE nfs4 *** Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de kernel: NFSv4: Unsupported transport protocol udp Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de automount[567]: >> mount.nfs: an incorrect mount option was specified Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de automount[567]: mount(nfs): nfs: mount failure NFSSERVER:/u/homes/XXX on /home/XXX Apr 27 16:27:20 Ankogel.nt.e-technik.tu-darmstadt.de automount[567]: failed to mount /home/XXX [...] AFAICS, the kernel has no business "validating" an nfsv4 mount, because none has been asked for. The 2020-03-09 setup: [...] Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de automount[546]: attempting to mount entry /home/XXX Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: Registered named UNIX socket transport module. Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: Registered udp transport module. Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: Registered tcp transport module. Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: RPC: Registered tcp NFSv4.1 backchannel transport module. Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de kernel: FS-Cache: Netfs 'nfs' registered for caching Apr 27 18:57:11 Ankogel.nt.e-technik.tu-darmstadt.de automount[546]: mounted /home/XXX [...] From what I can see, either I missed some obscure new configuration that overrides the automounter's explicit mount options. Or, I hit a kernel bug. Cheerio, Hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
[arch-general] NFS "updates"?
All, we have a group of Arch desktop clients that mount their user homes and group shares through nfsv3 over udp from an OmniOS server. After today's update (the last one was on 9 Mar) the machine will not nfs-mount, complaining about illegal udp, grpid, int mount options, and the kernel spits out a NFSV4: Unsupported transport protocol udp although nothing on this installation anywhere ever has used nfsv4 until now, and /etc/default/autofs explicitly specifies nfsv3. Editing /etc/nfsmount.conf (which was in default state until now) accordingly did not make a difference. I couldn't find any nfs related Arch news items. What did I miss? Cheerio, Hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] Arch pkg user and group IDs?
On Mon, 28 Nov 2016 12:28:23 +0100, Martin Kühne via arch-general wrote: > Hmm, you could do the move per-server, though, at least for the > network services that publicly can report a different UID/GID pair > than is advertised on the file system, which is at least true for NFS. NFSv4, that is. We use v3, which by design cannot remap IDs - the server takes the client's information as gospel. > Did you look into that, already? Yes... the NFS server is actually the least of my worries. Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] Arch pkg user and group IDs?
On Sun, 27 Nov 2016 19:16:56 -0700, Leonid Isaev wrote: > But out of curiosity, why is it difficult to change user IDs on all files? I > assume that you control the storage? Isn't it just a chown -R away? For > example, for our NIS passwd/shadow map we use 6-digit IDs... Because... users have files - on their NFS home - on public NFS shares - on a partition of the local harddrive (and not necessarily limited to one machine) - on their home on the web server - on their home on the mailserver - on their home on the computing cluster all of which makes a change of user and group id slightly more involved than a 'chmod -R'. Nothing that couldn't be done, mind you, given enough round tuits - both for me and my users. As I said, it would have to be either a flag day (deploy a script with old-new mapping to all machines involved, lock out users, shut down services, run script), or piecemeal change (negociate time slot with user, log them out, annoy other users because you have to temporarily disable imap and smtp services, run said script). Both would need to be planned, communicated and negociated, and so take more time than I have. Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] Arch pkg user and group IDs?
On Sun, 27 Nov 2016 15:49:33 -0500, Eli Schwartz via arch-general wrote: >> [login.defs] might actually help, depending on how well it is >> enforced. Thanks! > > "enforced"? It is the configuration file for useradd. Anything not > explicitly hardcoded in the UID/GID database (or hardcoded but not in > the database) ... like lightdm? > will respect the useradd configuration (when you reinstall > Arch and all those users are created from scratch again). > > Although really, whatever distribution was running on your NFS server > shouldn't be configuring for users with UIDs below 1000 -- a network is > exactly the wrong place to be allowing UIDs that can clash with other > distros' UID reservations. Well, there's <http://unix.stackexchange.com/questions/101313/what-are-the-dangers-of-creating-a-normal-user-with-uid-500> which discusses OS distributions' conventions of where to start non-system uids/gids. The installation in question is about 13 years old, and it has been merged a while back with a database that was even older. So the uid 1000 border that Arch uses (and also Debian, according to the link above, although at least Debian 7 is counting upward, and the highest system uid on our systems is 118), is by no means universal. I guess the average distro maintainer doesn't work in a larger, historically grown network... > It might not be a bad idea to report that as a bug. It was an administrative decision, back more than ten years ago, when 500 IDs appeared to be enough for everyone. ;) [ systemd-journal-remote:x:999: systemd-journal-upload:x:998: systemd-coredump:x:997: ] > AFAIK those systemd users/groups are generated by sysusers.d Aahh! Thanks for the missing puzzle piece. I guess I can find my way from there. Cheerio, Hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] Arch pkg user and group IDs?
On Sun, 27 Nov 2016 08:55:48 -0500, Eli Schwartz via arch-general wrote: > By convention, Arch expects user UIDs to be greater than 1000. I understand that. > There is a list of explicitly reserved system UIDs by repo packages > here: https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database Which, apart from qmail which is easily avoided, lists only IDs below 500. But it looks like /etc/login.defs additionally reserves a range of system IDs. Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
Re: [arch-general] Arch pkg user and group IDs?
On Sun, 27 Nov 2016 14:52:25 +0100, Martin Kühne via arch-general wrote: > What I would recommend to you is to use another range further beyond > 1000 for your network users and groups because with regard to what we > established in the first paragraph, those don't seem to qualify as > system users IMO. Well, since we are talking about an existing system with a few dozen users and more machines, plus a few servers, moving existing users and groups is a last resort, and one that will create unhappiness and bad fallout. I would rather not go there. > And, just to mention it for completness, there is > /etc/login.defs where you can theoretically adjust those numbers. This # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 6 # System accounts SYS_UID_MIN 500 SYS_UID_MAX 999 might actually help, depending on how well it is enforced. Thanks! Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344
[arch-general] Arch pkg user and group IDs?
Hi,
what are Arch's conventions for the numeric ranges of system (package)
user and grop IDs? And can the range be limited?
I am working up to switching a few dozen Debian clients to Arch. They
have user homes on NFS, and authenticate through NIS. So far, nis
distributes user and group IDs > 500, making anything lower a local /
system ID. After installing Arch, I see
% awk -F: '{ if ( $3 > 500 ) print }' < /etc/passwd
systemd-journal-remote:x:999:999:systemd Journal Remote:/:/sbin/nologin
systemd-journal-upload:x:998:998:systemd Journal Upload:/:/sbin/nologin
systemd-coredump:x:997:997:systemd Core Dumper:/:/sbin/nologin
% awk -F: '{ if ( $3 > 500 ) print }' < /etc/group
systemd-journal-remote:x:999:
systemd-journal-upload:x:998:
systemd-coredump:x:997:
lightdm:x:620:
%
which collide with NIS users.[1]
My question: Do Arch packages come with hardcoded numerical user/group
IDs? If not, is there a way to limit the numeric range of system IDs? I
guess I would still have to reinstall the distribution.
The alternative - a flag day to change NIS user and group IDs as well
as on 4 TB file storage and local storage on 50 client machines -
wouldn't be pretty. And I don't really have the time, either.
Cheerio,
hauke
[1] lightdm appears to be a pathological case: It hardcodes both name
and ID of its user and group, and installation plows on witjout
flagging an error even after failing to register the user ID.
--
The ASCII Ribbon Campaign Hauke Fath
() No HTML/RTF in emailInstitut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-21344
