Updating iputils over NFS
 

I'm having an issue updating a system that boots over NFS. Attempting to
upgrade the iputils package results in the following:

---8<-------------------------------
(1/1) upgrading iputils
[###########################] 100%
Failed to set capabilities on file `usr/bin/ping' (Operation not supported)
usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>)
<filenameN> ]

Note <filename> must be a regular (non-symlink) file.
Failed to set capabilities on file `usr/bin/ping6' (Operation not supported)
usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>)
<filenameN> ]

Note <filename> must be a regular (non-symlink) file.
---8<-------------------------------

I suspect this is something to do with NFS not supporting the capabilities
that setcap is trying to use, but I admit I haven't encountered capabilities
before I ran into this issue, so it's just a guess.

Has anyone else seen this problem, or does anyone have an idea how to fix it?

Paul

Updating iputils over NFS
 

On 09/28/2012 11:19 AM, Paul Gideon Dann wrote:
> I'm having an issue updating a system that boots over NFS. Attempting to
> upgrade the iputils package results in the following:
>
> ---8<-------------------------------
> (1/1) upgrading iputils
> [###########################] 100%
> Failed to set capabilities on file `usr/bin/ping' (Operation not supported)
> usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>)
> <filenameN> ]
>
> Note <filename> must be a regular (non-symlink) file.
> Failed to set capabilities on file `usr/bin/ping6' (Operation not supported)
> usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>)
> <filenameN> ]
>
> Note <filename> must be a regular (non-symlink) file.
> ---8<-------------------------------
>
> I suspect this is something to do with NFS not supporting the capabilities
> that setcap is trying to use, but I admit I haven't encountered capabilities
> before I ran into this issue, so it's just a guess.
>
> Has anyone else seen this problem, or does anyone have an idea how to fix it?
NFS doesn't support any capibilities, so I guess the output is to be expected... I'm not sure what to do as a workaround, though. Does the package still install and run even though it printed the warning?

- Bryan

>
> Paul

Updating iputils over NFS
 

On Friday 28 Sep 2012 16:32:09 Bryan Schumaker wrote:
> > I suspect this is something to do with NFS not supporting the capabilities
> > that setcap is trying to use, but I admit I haven't encountered
> > capabilities before I ran into this issue, so it's just a guess.
> >
> > Has anyone else seen this problem, or does anyone have an idea how to fix
> > it?
> NFS doesn't support any capibilities, so I guess the output is to be
> expected... I'm not sure what to do as a workaround, though. Does the
> package still install and run even though it printed the warning?

Hmm; yeah. Well the package installs, but ping doesn't work for non-root
users. It's not a critical issue, because these are network-booted worker
nodes in a cluster, and I doubt ping will be needed directly on the nodes.
However, it worries me that other things might be affected at some point if
capabilities are increasingly used. I might put in a bug report and see what
the devs think.

(I am subscribed to the list, btw.)

Paul

Updating iputils over NFS
 

Am 01.10.2012 11:05, schrieb Paul Gideon Dann:
> On Friday 28 Sep 2012 16:32:09 Bryan Schumaker wrote:
>>> I suspect this is something to do with NFS not supporting the capabilities
>>> that setcap is trying to use, but I admit I haven't encountered
>>> capabilities before I ran into this issue, so it's just a guess.
>>>
>>> Has anyone else seen this problem, or does anyone have an idea how to fix
>>> it?
>> NFS doesn't support any capibilities, so I guess the output is to be
>> expected... I'm not sure what to do as a workaround, though. Does the
>> package still install and run even though it printed the warning?
>
> Hmm; yeah. Well the package installs, but ping doesn't work for non-root
> users. It's not a critical issue, because these are network-booted worker
> nodes in a cluster, and I doubt ping will be needed directly on the nodes.
> However, it worries me that other things might be affected at some point if
> capabilities are increasingly used. I might put in a bug report and see what
> the devs think.

The lack of capability support on NFS is a shame. In general, we should
probably fall back to setuid-root whenever setcap fails and silence this
error message.

In my opinion, capabilities should be used much more widely and replace
setuid-root whereever possible.

Updating iputils over NFS
 

Am 01.10.2012 11:05, schrieb Paul Gideon Dann:
> On Friday 28 Sep 2012 16:32:09 Bryan Schumaker wrote:
>>> I suspect this is something to do with NFS not supporting the capabilities
>>> that setcap is trying to use, but I admit I haven't encountered
>>> capabilities before I ran into this issue, so it's just a guess.
>>>
>>> Has anyone else seen this problem, or does anyone have an idea how to fix
>>> it?
>> NFS doesn't support any capibilities, so I guess the output is to be
>> expected... I'm not sure what to do as a workaround, though. Does the
>> package still install and run even though it printed the warning?
>
> Hmm; yeah. Well the package installs, but ping doesn't work for non-root
> users. It's not a critical issue, because these are network-booted worker
> nodes in a cluster, and I doubt ping will be needed directly on the nodes.
> However, it worries me that other things might be affected at some point if
> capabilities are increasingly used. I might put in a bug report and see what
> the devs think.

The lack of capability support on NFS is a shame. In general, we should
probably fall back to setuid-root whenever setcap fails and silence this
error message.

In my opinion, capabilities should be used much more widely and replace
setuid-root whereever possible.

Updating iputils over NFS
 

On Monday 01 Oct 2012 11:09:05 Thomas Bächler wrote:
> The lack of capability support on NFS is a shame. In general, we should
> probably fall back to setuid-root whenever setcap fails and silence this
> error message.
>
> In my opinion, capabilities should be used much more widely and replace
> setuid-root whereever possible.

Agreed. I think setuid as a fallback is the solution here, but that could be
a bit of a nightmare for package maintainers to deal with.

I created this bug report:
https://bugs.archlinux.org/task/31748

Paul

Updating iputils over NFS
 

Le 2012-10-01 05:09, Thomas Bächler a écrit :

Am 01.10.2012 11:05, schrieb Paul Gideon Dann:

On Friday 28 Sep 2012 16:32:09 Bryan Schumaker wrote:

I suspect this is something to do with NFS not supporting the capabilities
that setcap is trying to use, but I admit I haven't encountered
capabilities before I ran into this issue, so it's just a guess.

Has anyone else seen this problem, or does anyone have an idea how to fix
it?

NFS doesn't support any capibilities, so I guess the output is to be
expected... I'm not sure what to do as a workaround, though. Does the
package still install and run even though it printed the warning?

Hmm; yeah. Well the package installs, but ping doesn't work for non-root
users. It's not a critical issue, because these are network-booted worker
nodes in a cluster, and I doubt ping will be needed directly on the nodes.
However, it worries me that other things might be affected at some point if
capabilities are increasingly used. I might put in a bug report and see what
the devs think.

The lack of capability support on NFS is a shame. In general, we should
probably fall back to setuid-root whenever setcap fails and silence this
error message.

In my opinion, capabilities should be used much more widely and replace
setuid-root whereever possible.


I am not sure what is the best way to fall back to suid root. A possible
workaround for the case of installing on a filesystem that does not
support capabilities could be something like :


setcap cap_net_raw=ep usr/bin/ping || chmod +s usr/bin/ping

But I think that we will still get into problems if it is installed on a
filesystems that support capabilities and if this filesystem is exported
on NFS to clients.


Any ideas ?

Stéphane

Updating iputils over NFS
 

Am 01.10.2012 14:15, schrieb Stéphane Gaudreault:
> I am not sure what is the best way to fall back to suid root. A possible
> workaround for the case of installing on a filesystem that does not
> support capabilities could be something like :
>
> setcap cap_net_raw=ep usr/bin/ping || chmod +s usr/bin/ping
>
> But I think that we will still get into problems if it is installed on a
> filesystems that support capabilities and if this filesystem is exported
> on NFS to clients.

If you run the post_install on the host file system and export that via
NFS, yes - but we have no way to detect this scenario.

IMO, root file systems on NFS are a failure by design anyway - I worked
in such a scenario for years and it is a bad bad bad idea. While we
should fix easy problems such as this one, we should not spend too much
time on making this work.

> Any ideas ?

Your solution looks fine, but the message should be silenced with
2>/dev/null.

Updating iputils over NFS
 

On Monday 01 Oct 2012 14:22:41 Thomas Bächler wrote:
> IMO, root file systems on NFS are a failure by design anyway - I worked
> in such a scenario for years and it is a bad bad bad idea. While we
> should fix easy problems such as this one, we should not spend too much
> time on making this work.

I'd be really interested in your reasons for this. I'm running a network-
booted cluster, and things seem much easier using NFS for this than it would
be to have a hard disk in each node and use puppet (or similar) for
administration.

Paul

Updating iputils over NFS
 

Am 01.10.2012 15:21, schrieb Paul Gideon Dann:
> On Monday 01 Oct 2012 14:22:41 Thomas Bächler wrote:
>> IMO, root file systems on NFS are a failure by design anyway - I worked
>> in such a scenario for years and it is a bad bad bad idea. While we
>> should fix easy problems such as this one, we should not spend too much
>> time on making this work.
>
> I'd be really interested in your reasons for this. I'm running a network-
> booted cluster, and things seem much easier using NFS for this than it would
> be to have a hard disk in each node and use puppet (or similar) for
> administration.

We have a 100MBit/s network, which may or may not be the bottleneck
Loading a modern desktop environment like KDE over NFS just takes too
long. A user needs to wait up to 5 minutes after login, starting
applications isn't instant, everything feels like 10 years ago
speed-wise. The same goes for boot times.

The worst part however is that booting a Linux system over NFS never
works quite right out of the box, you need too many tricks to make it
work smoothly.

As lot of the OS is shared, upgrading parts of the system while it is
running leads to problems. There is no way to share the entire system
EXCEPT a number of config files.

All my machines now have a small hard drive or SSD and have an option in
the boot menu to sync an updated operating system on reboot - this uses
rsync and --exclude to omit certain config files that are per-machine.
Administration of this scheme has proven much easier and more robust
than the old NFS-based one.