Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-04 Thread James Hogarth 
On 4 Feb 2016 03:10, "Always Learning"  wrote:
>
>
> On Wed, 2016-02-03 at 13:57 -0700, Warren Young wrote:
>
> > On Feb 3, 2016, at 10:30 AM, Ricardo J. Barberis 
wrote:
> > >
> > > El Miércoles 03/02/2016, Warren Young escribió:
> > >>
> > >> Again, I don’t know why they couldn’t just do it with links.
> > >
> > > I guess that's probably to execute scripts and "hide" the name of the
> > > interpreter, e.g.:
> >
> > I get why second-rate programmers would care to do that, but what I
don’t get is why systemd would need a feature to support that wish.
>
> Perhaps the Systemd are all 'second-rate' programmers ?  Good
> programmers always try to avoid the crap.
>
>

That's enough.

You've been around these lists long enough to realise attacks like that
nonsense are inappropriate and won't be tolerated.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread Warren Young 
On Feb 3, 2016, at 10:18 AM, Gordon Messmer  wrote:
> 
> On 02/03/2016 08:59 AM, Warren Young wrote:
>> Again, I don’t know why they couldn’t just do it with links.
> 
> Probably because they want to support a read-only root filesystem, working 
> toward "stateless" systems.

How does that explain anything?  The same RPM that installed the service file 
can create a hard link or symlink giving the command an alternate name.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread Gordon Messmer 

On 02/03/2016 12:52 PM, Warren Young wrote:

Probably because they want to support a read-only root filesystem, working toward 
"stateless" systems.

How does that explain anything?  The same RPM that installed the service file 
can create a hard link or symlink giving the command an alternate name.


It might not be the package that includes the symlink.  It may be the 
admin who wants it.  Where the root fs is read-only, this feature is an 
alternative to creating a symlink.


It seems to be a thing that people want, in any case:
http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/7759


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread Warren Young 
On Feb 3, 2016, at 10:30 AM, Ricardo J. Barberis  wrote:
> 
> El Miércoles 03/02/2016, Warren Young escribió:
>> 
>> Again, I don’t know why they couldn’t just do it with links.
> 
> I guess that's probably to execute scripts and "hide" the name of the 
> interpreter, e.g.:

I get why second-rate programmers would care to do that, but what I don’t get 
is why systemd would need a feature to support that wish.

No, I suspect the real reason systemd needs to support this is to work around 
someone’s broken argv[0] parsing.  For instance, there may be a program that 
assumes it is always started through the PATH, so argv[0] never contains 
slashes.  But, systemd only works with absolute paths for security, so rather 
than fix the broken program, they added a feature to systemd that lets it lie 
to the broken program, supplying the program’s basename in argv[0] even though 
it was started via an absolute path.

Just a guess, of course.

I notice that none of the service files on my main EL7 box use this leading-@ 
feature.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread Always Learning 

On Wed, 2016-02-03 at 13:57 -0700, Warren Young wrote:

> On Feb 3, 2016, at 10:30 AM, Ricardo J. Barberis  
> wrote:
> > 
> > El Miércoles 03/02/2016, Warren Young escribió:
> >> 
> >> Again, I don’t know why they couldn’t just do it with links.
> > 
> > I guess that's probably to execute scripts and "hide" the name of the 
> > interpreter, e.g.:
> 
> I get why second-rate programmers would care to do that, but what I don’t get 
> is why systemd would need a feature to support that wish.

Perhaps the Systemd are all 'second-rate' programmers ?  Good
programmers always try to avoid the crap.


-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread Noam Bernstein 
> On Feb 3, 2016, at 10:57 AM, m.r...@5-cent.us wrote:
> 
> The issue: NFS fails to start in CentOS 7 if it cannot resolve any of a
> list of hosts.
> 
> Well, my manager had to google to find the *truly* obscure solution that
> uses a deeply oddball syntax.
> 
> In /usr/lib/systemd/system/nfs-server.service, you edit the following line
> so that it looks like this:
> ExecStartPre=-/usr/sbin/exportfs -r
> 
> Notice the *deeply* weird syntax of "=-". This apparently tells it
> that "a nonzero exit code" should be ignored and considered "success”.

Deeply weird or not, this is standard make (or at least gnu make) syntax.  I 
wouldn’t be surprised if the developers thought it was completely normal.

> 
> And, I read in the manpage for systemd.service that if you precede it with
> an @, it will pass arguments. Why it does not use the used-everywhere-else
> of *post*fixing those parms, I have no data.

My reading of the man page is that arguments are always passed, and @ just 
means that the first “argument” (i.e. 1st token after the executable name) is 
passed as argv[0] (which would normally the path of the executable itself).  
But that’s entirely based on the man page, no actual experience.

Noam
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread Warren Young 
On Feb 3, 2016, at 8:57 AM, m.r...@5-cent.us wrote:
> 
> Notice the *deeply* weird syntax of "=-”.

That syntax comes from make(1), where it means the same thing.  make(1) has 
been with us since 1977, so I’d think “old and familiar” is a better 
description than “deeply weird.”

> And, I read in the manpage for systemd.service that if you precede it with
> an @, it will pass arguments. Why it does not use the used-everywhere-else
> of *post*fixing those parms, I have no data.

You’ve misread the page.

All this option does is lets you run one command but tell the command itself 
that it was called by a different name.  I’m not sure why the systemd creators 
added this, since you normally get this behavior with links:

$ sudo yum install unzip
$ ls -li /bin/unzip /bin/infozip
135096149 -rwxr-xr-x.   2 root root 181248 Mar 18  2015 unzip 
135096149 -rwxr-xr-x.   2 root root 181248 Mar 18  2015 zipinfo   

That is, we have a single program binary with two different names.  Invoking 
the program as “zipinfo” makes it behave differently than if you invoke it as 
“unzip”.

All this systemd feature does is lets you say something like:

ExecStart=@/bin/unzip zipinfo ...

That is, you can run the unzip binary but *call it* zipinfo.

Again, I don’t know why they couldn’t just do it with links.  However, I will 
point out that the C programming interfaces on your system (execv() and 
friends) also support this feature, and have since back before 1977, so that 
this, too, is not some fresh new weirdness.

> I also don't
> understand why you'd set as an out-of-the-box default that it should fail
> to come up if it can't resolve any export host, rather than default to
> coming up.

You do it for the same reason you’d fail when mounting any other filesystem.  
It may be critical to operation, as with shared /usr.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread m . roth 
Warren Young wrote:
> On Feb 3, 2016, at 8:57 AM, m.r...@5-cent.us wrote:
>>
>> I also don't understand why you'd set as an out-of-the-box default
>> that it should fail to come up if it can't resolve any export host,
>> rather than default to coming up.
>
> You do it for the same reason you’d fail when mounting any other
> filesystem.  It may be critical to operation, as with shared /usr.

Beg pardon? The NFS server is offering it out, not requiring the f/s in.
How could it be considered critical, as mounting / is? I can see it if
*networking's* not up, but when it's only members of a list to whom it is
available?

  mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread m . roth 
The issue: NFS fails to start in CentOS 7 if it cannot resolve any of a
list of hosts.

Well, my manager had to google to find the *truly* obscure solution that
uses a deeply oddball syntax.

In /usr/lib/systemd/system/nfs-server.service, you edit the following line
so that it looks like this:
 ExecStartPre=-/usr/sbin/exportfs -r

Notice the *deeply* weird syntax of "=-". This apparently tells it
that "a nonzero exit code" should be ignored and considered "success".

And, I read in the manpage for systemd.service that if you precede it with
an @, it will pass arguments. Why it does not use the used-everywhere-else
of *post*fixing those parms, I have no data.

And, speaking specifically about nfs-server.service, I also don't
understand why you'd set as an out-of-the-box default that it should fail
to come up if it can't resolve any export host, rather than default to
coming up.

   mark, discovering new reasons to dislike systemd

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread Ricardo J. Barberis 
El Miércoles 03/02/2016, Warren Young escribió:
> On Feb 3, 2016, at 8:57 AM, m.r...@5-cent.us wrote:
> > Notice the *deeply* weird syntax of "=-”.
>
> That syntax comes from make(1), where it means the same thing.  make(1) has
> been with us since 1977, so I’d think “old and familiar” is a better
> description than “deeply weird.”
>
> > And, I read in the manpage for systemd.service that if you precede it
> > with an @, it will pass arguments. Why it does not use the
> > used-everywhere-else of *post*fixing those parms, I have no data.
>
> You’ve misread the page.
>
> All this option does is lets you run one command but tell the command
> itself that it was called by a different name.  I’m not sure why the
> systemd creators added this, since you normally get this behavior with
> links:
>
> $ sudo yum install unzip
> $ ls -li /bin/unzip /bin/infozip
> 135096149 -rwxr-xr-x.   2 root root 181248 Mar 18  2015 unzip
> 135096149 -rwxr-xr-x.   2 root root 181248 Mar 18  2015 zipinfo
>
> That is, we have a single program binary with two different names. 
> Invoking the program as “zipinfo” makes it behave differently than if you
> invoke it as “unzip”.
>
> All this systemd feature does is lets you say something like:
>
> ExecStart=@/bin/unzip zipinfo ...
>
> That is, you can run the unzip binary but *call it* zipinfo.
>
> Again, I don’t know why they couldn’t just do it with links.  However, I
> will point out that the C programming interfaces on your system (execv()
> and friends) also support this feature, and have since back before 1977, so
> that this, too, is not some fresh new weirdness.

I guess that's probably to execute scripts and "hide" the name of the 
interpreter, e.g.:

ExecStart=@/usr/bin/python my_cool_service --my_args


> > I also don't
> > understand why you'd set as an out-of-the-box default that it should fail
> > to come up if it can't resolve any export host, rather than default to
> > coming up.
>
> You do it for the same reason you’d fail when mounting any other
> filesystem.  It may be critical to operation, as with shared /usr.


-- 
Ricardo J. Barberis
Usuario Linux Nº 250625: http://counter.li.org/
Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
Senior SysAdmin / IT Architect - www.DonWeb.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7, NSF, "feature" [SOLVED]

2016-02-03 Thread Gordon Messmer 

On 02/03/2016 08:59 AM, Warren Young wrote:

Again, I don’t know why they couldn’t just do it with links.


Probably because they want to support a read-only root filesystem, 
working toward "stateless" systems.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos