[PATCH RFC] Install puppet admin commands in sbindir
Todd Zullinger
sbindir by default. Many puppet packages already did this.
Signed-off-by: Todd Zullinger <t...@pobox.com>
---
I was looking at using the install.rb script in the Fedora and EPEL
spec files instead of manually installing all the files. In the
process, I found the default install location for puppetca, puppetd,
and puppetmasterd, and puppetrun was bindir rather than sbindir.
For Fedora and EPEL, we'd want to install in sbindir, to better match
the FHSน. Debian also installs these files in sbindir. Technically,
Fedora is currently installing puppetrun in bindir, but I think the
Debian placement in sbindir makes more sense.
SUSE also installs most of these files in sbindir in their packages.
Archlinux and OpenBSD both appear to use bindir. I didn't look
closely enough to see where Mandriva and Gentoo put things.
The question is whether changing the default is worthwhile or not?
I'd love to be able to use the install.rb script for installation, but
I'd be hard pressed to drop all of the scripts into bindir, as that
would violate the Fedora packaging guidelines. But if many of the
OS/distro packages are already installing the daemons and other admin
scripts to sbindir, perhaps making that the default as shipped
upstream makes sense?
Thoughts, comments, pitchfork wielding mobs at my doorstep?
น Filesystem Hierarchy Standard for those not familiar with that
particular TLA.
{bin => sbin}/puppetca | 0
{bin => sbin}/puppetd | 0
{bin => sbin}/puppetmasterd | 0
{bin => sbin}/puppetrun | 0
4 files changed, 0 insertions(+), 0 deletions(-)
rename {bin => sbin}/puppetca (100%)
rename {bin => sbin}/puppetd (100%)
rename {bin => sbin}/puppetmasterd (100%)
rename {bin => sbin}/puppetrun (100%)
diff --git a/bin/puppetca b/sbin/puppetca
similarity index 100%
rename from bin/puppetca
rename to sbin/puppetca
diff --git a/bin/puppetd b/sbin/puppetd
similarity index 100%
rename from bin/puppetd
rename to sbin/puppetd
diff --git a/bin/puppetmasterd b/sbin/puppetmasterd
similarity index 100%
rename from bin/puppetmasterd
rename to sbin/puppetmasterd
diff --git a/bin/puppetrun b/sbin/puppetrun
similarity index 100%
rename from bin/puppetrun
rename to sbin/puppetrun
--
1.6.2
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I personally think we developed language because of our deep need to
complain.
-- Lily Tomlin
Larry Ludwig
On Mar 11, 2009, at 3:38 AM, Todd Zullinger wrote:
>
> This moves puppetca, puppetd, and puppetmasterd, and puppetrun to
> sbindir by default. Many puppet packages already did this.
>
>
+1. Not only that but it should be consistent across platforms so
it's easier to script things. I see no reason why non privileged
users should have access to these apps anyways.
-L
--
Larry Ludwig
Nigel Kersten
So this is going to pose some interesting questions for us package maintainers.
Do we automatically remove these files out of bindir if they exist?
(ie for users who are upgrading)
I think that's the only real option. I'll have to patch the OS X
package preflights if this is the case.
--
Nigel Kersten
Systems Administrator
Tech Lead - MacOps
Luke Kanies
>
> This moves puppetca, puppetd, and puppetmasterd, and puppetrun to
> sbindir by default. Many puppet packages already did this.
I'm all for this, but I gave up when I tried to do it myself (which
was, admittedly, a while ago). I believe that the reason I gave up
was that our install and/or build system is a bit fragile, and I
couldn't easily figure out how to adjust it all to work correctly.
I think this is a good patch for 0.25 but not for 0.24.8. All of the
package maintainers, I think, will need to modify their build scripts,
so we should give them fair warning.
We need some sort of list of the people maintaining packages, so they
can be sure they'll get notified. :/
--
The remarkable thing about Shakespeare is that he really is very good,
in spite of all the people who say he is very good. -- Robert Graves
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies
Heh, well, *most* packagers don't have that problem, since their OS
packages handle it for them. :)
But yeah, this should actually be done for all files in both Puppet
and Facter packages - otherwise you get issues where an old file that
is removed in the repo remains on the filesystem, gets autoloaded, and
refers to a class that no longer exists. This happened with the
Facter 1.5.3 => 1.5.4 transition, I think.
--
Happiness is not achieved by the conscious pursuit of happiness; it is
generally the by-product of other activities. -- Aldous Huxley
Nigel Kersten
>
> On Mar 11, 2009, at 10:42 AM, Nigel Kersten wrote:
>
>>
>> On Wed, Mar 11, 2009 at 8:36 AM, Larry Ludwig
>> <la...@reductivelabs.com> wrote:
>>>
>>>
>>> On Mar 11, 2009, at 3:38 AM, Todd Zullinger wrote:
>>>
>>>>
>>>> This moves puppetca, puppetd, and puppetmasterd, and puppetrun to
>>>> sbindir by default. Many puppet packages already did this.
>>>>
>>>
>>>>
>>>
>>> +1. Not only that but it should be consistent across platforms so
>>> it's easier to script things. I see no reason why non privileged
>>> users should have access to these apps anyways.
>>
>> So this is going to pose some interesting questions for us package
>> maintainers.
>>
>> Do we automatically remove these files out of bindir if they exist?
>> (ie for users who are upgrading)
>>
>> I think that's the only real option. I'll have to patch the OS X
>> package preflights if this is the case.
>
> Heh, well, *most* packagers don't have that problem, since their OS
> packages handle it for them. :)
>
> But yeah, this should actually be done for all files in both Puppet
> and Facter packages - otherwise you get issues where an old file that
> is removed in the repo remains on the filesystem, gets autoloaded, and
> refers to a class that no longer exists. This happened with the
> Facter 1.5.3 => 1.5.4 transition, I think.
There was a bug in the preflight script in facter for OS X that I've
fixed in the packages I distribute and upstream, but it should be
doing this anyway.
/bin/rm -Rf "${3}{SITELIBDIR}/facter"
/bin/rm -Rf "${3}{SITELIBDIR}/facter.rb"
There was a missing brace which meant that it was failing to
substitute SITELIBDIR correctly.
It won't cope with a package that is built to install to one site lib
dir, but an old installation is in a different location, but I think
people can cope with those problems if they're building them
themselves.
++ to waiting for 0.25 for this patch, as much as I agree it is the
correct thing to do.
Larry Ludwig
On Mar 11, 2009, at 11:42 AM, Nigel Kersten wrote:
>
>
> Do we automatically remove these files out of bindir if they exist?
> (ie for users who are upgrading)
That would make the most sense and also state this change clearly in
our change logs and a note to upgraders using the packages where this
does change. Also like Luke mentioned to put it into 0.26 release so
everyone has time for this change. Even worst case you can put sym
links in if needed.
-L
Todd Zullinger
> I'm all for this, but I gave up when I tried to do it myself (which
> was, admittedly, a while ago). I believe that the reason I gave up
> was that our install and/or build system is a bit fragile, and I
> couldn't easily figure out how to adjust it all to work correctly.
I may well not know enough about rake and rubygems to get this all
right, but I think the attached patch does the right thing, in as much
as I was able to test creating a release locally. The .gem and .tgz
file created look sane to me. The only oddity I noticed is that the
paths for the bin and sbin files in the data.tar.gz inside the gem
were ./bin/... rather than just bin/... But that seems to be just an
ugly wart which only a few people poking the gem file would ever see
(and even fewer would care about).
Incidentally, I made two small changes to tasks/rake/reductive.rb to
make it easier for me to run rake release on my own system (to respect
the DOWNLOAD_DIR variable and create the apidocs dir as needed). Are
these patches you might be interested in? And it so, should I make
them against the files in the puppet repo or the reductive-build repo?
> I think this is a good patch for 0.25 but not for 0.24.8.
What? You don't want to push a large renaming of commands into a
stable bugfix release? Where's your sense of adventure. ;)
But seriously, I agree this is something that should be allowed to
simmer for a while before it hits a release.
> All of the package maintainers, I think, will need to modify their
> build scripts, so we should give them fair warning.
>
> We need some sort of list of the people maintaining packages, so
> they can be sure they'll get notified. :/
I'd be happy to try and track down and mail the maintainers of all the
packages listed at on the wiki's DownloadingPuppet¹ page. Getting
input from other packagers on which binaries should be in bin versus
sbin would be ideal so that we don't have spurious differences between
systems, as Larry mentioned. If we get the defaults to be agreeable
to most packagers, we can all hopefully help make the install.rb
script to the right thing and save everyone some work.
Ideally, anyone maintaining a puppet package should try to follow this
list (or the user list at least). But I realize that's probably not
always the case.
¹ http://reductivelabs.com/trac/puppet/wiki/DownloadingPuppet
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First, God created idiots. That was just for practice. Then He created
school boards.
-- Mark Twain
Luke Kanies
> Luke Kanies wrote:
>> I'm all for this, but I gave up when I tried to do it myself (which
>> was, admittedly, a while ago). I believe that the reason I gave up
>> was that our install and/or build system is a bit fragile, and I
>> couldn't easily figure out how to adjust it all to work correctly.
>
> I may well not know enough about rake and rubygems to get this all
> right, but I think the attached patch does the right thing, in as much
> as I was able to test creating a release locally. The .gem and .tgz
> file created look sane to me. The only oddity I noticed is that the
> paths for the bin and sbin files in the data.tar.gz inside the gem
> were ./bin/... rather than just bin/... But that seems to be just an
> ugly wart which only a few people poking the gem file would ever see
> (and even fewer would care about).
Strange, but yeah, no biggie.
>
> Incidentally, I made two small changes to tasks/rake/reductive.rb to
> make it easier for me to run rake release on my own system (to respect
> the DOWNLOAD_DIR variable and create the apidocs dir as needed). Are
> these patches you might be interested in? And it so, should I make
> them against the files in the puppet repo or the reductive-build repo?
The reductive-build repo, please.
>
>> I think this is a good patch for 0.25 but not for 0.24.8.
>
> What? You don't want to push a large renaming of commands into a
> stable bugfix release? Where's your sense of adventure. ;)
Way dead. Way.
>
> But seriously, I agree this is something that should be allowed to
> simmer for a while before it hits a release.
>
>> All of the package maintainers, I think, will need to modify their
>> build scripts, so we should give them fair warning.
>>
>> We need some sort of list of the people maintaining packages, so
>> they can be sure they'll get notified. :/
>
> I'd be happy to try and track down and mail the maintainers of all the
> packages listed at on the wiki's DownloadingPuppet¹ page. Getting
> input from other packagers on which binaries should be in bin versus
> sbin would be ideal so that we don't have spurious differences between
> systems, as Larry mentioned. If we get the defaults to be agreeable
> to most packagers, we can all hopefully help make the install.rb
> script to the right thing and save everyone some work.
That would be great. I am planning on a month of release candidates
for 0.25, given how much is different and how subtle those differences
are likely to appear, so this should give packagers plenty of time. I
still sometimes fool myself into thinking we'll get an rc1 this month.
>
> Ideally, anyone maintaining a puppet package should try to follow this
> list (or the user list at least). But I realize that's probably not
> always the case.
>
> ¹ http://reductivelabs.com/trac/puppet/wiki/DownloadingPuppet
--
Tradition is what you resort to when you don't have the time or the
money to do it right. -- Kurt Herbert Alder
James Turnbull
Hash: SHA1
Todd
Can you please log tickets for each patch. Thanks.
Regards
James
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJuCZg9hTGvAxC30ARAnMaAJwMjLSx3u9g/fg45AbEzA9uZH15PgCaAhZp
qMSPAlFfuRjdjHyIJUKXf+o=
=M2VS
-----END PGP SIGNATURE-----
Larry Ludwig
in place or else I'll have to do some patching of my own before
install puppet on a remote machine.
-L
Todd Zullinger
> Can you please log tickets for each patch. Thanks.
Hopefully you meant the small build system patches. They were quite
tiny, so I filed them together as:
http://projects.reductivelabs.com/issues/2086
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When I think about all the crap I learned in high school ... it's a
wonder I can think at all.
-- Paul Simon
Luke Kanies
get to it tomorrow or so. Seem good on first pass.
--
Between two evils, I always pick the one I never tried before.
-- Mae West
James Turnbull
Hash: SHA1
Todd Zullinger wrote:
> This moves puppetca, puppetd, and puppetmasterd, and puppetrun to
> sbindir by default. Many puppet packages already did this.
>
I've left this for the moment until we get some more consensus.
Regards
James
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJw2Q49hTGvAxC30ARAsLwAKDK0OuSu9F16KroH6VtRAG8xki1qQCeNcH6
vJ1GhiBxaZxhyPh+JJMj/ZM=
=MOQZ
-----END PGP SIGNATURE-----
Luke Kanies
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Todd Zullinger wrote:
>> This moves puppetca, puppetd, and puppetmasterd, and puppetrun to
>> sbindir by default. Many puppet packages already did this.
>>
>
> I've left this for the moment until we get some more consensus.
What consensus is there left to get? I thought it was relatively
consistent.
--
I never think of the future. It comes soon enough. --Albert Einstein
James Turnbull
> On Mar 20, 2009, at 4:39 AM, James Turnbull wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Todd Zullinger wrote:
>>> This moves puppetca, puppetd, and puppetmasterd, and puppetrun to
>>> sbindir by default. Many puppet packages already did this.
>>>
>> I've left this for the moment until we get some more consensus.
>
> What consensus is there left to get? I thought it was relatively
> consistent.
>
That's be not all the packagers agree with the patch and several haven't
responded. That not consensus.
Regards
James
Larry Ludwig
On Mar 20, 2009, at 10:35 AM, James Turnbull wrote:
> Luke Kanies wrote:
>> On Mar 20, 2009, at 4:39 AM, James Turnbull wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Todd Zullinger wrote:
>>>> This moves puppetca, puppetd, and puppetmasterd, and puppetrun to
>>>> sbindir by default. Many puppet packages already did this.
>>>>
>>> I've left this for the moment until we get some more consensus.
>>
>> What consensus is there left to get? I thought it was relatively
>> consistent.
>>
>
> That's be not all the packagers agree with the patch and several
> haven't
> responded. That not consensus.
>
Who needs to respond?
-L
James Turnbull
>> That's be not all the packagers agree with the patch and several
>> haven't
>> responded. That not consensus.
>>
>
> Who needs to respond?
I hadn't seen anything from the Debian guys or Nigel.
James Turnbull
Hash: SHA1
James Turnbull wrote:
> Larry Ludwig wrote:
>
>>> That's be not all the packagers agree with the patch and several
>>> haven't
>>> responded. That not consensus.
>>>
>> Who needs to respond?
>
> I hadn't seen anything from the Debian guys or Nigel.
>
> James
>
After discussion - this seems reasonable and since the major distros
seem happy - it's pushed in 0.25.0 in commit
3e0a9cda8c6f3866c85fd20dd56a6bafcc0e0db7.
Regards
James
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJw7Zc9hTGvAxC30ARAnPIAJ0dICcD8N7hMNWTU6OudE5QHnzkAwCeItGe
IPzkWe7LOQl7fdbX+UhGnKA=
=RAuA
-----END PGP SIGNATURE-----
Nigel Kersten
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> James Turnbull wrote:
>> Larry Ludwig wrote:
>>
>>>> That's be not all the packagers agree with the patch and several
>>>> haven't
>>>> responded. That not consensus.
>>>>
>>> Who needs to respond?
>>
>> I hadn't seen anything from the Debian guys or Nigel.
>>
>> James
>>
>
> After discussion - this seems reasonable and since the major distros
> seem happy - it's pushed in 0.25.0 in commit
> 3e0a9cda8c6f3866c85fd20dd56a6bafcc0e0db7.
Sorry, I think I commented in some other thread. Pushing back to 0.25
is my favourite outcome.