Brian K. White typed (on Wed, Aug 24, 2005 at 04:28:31PM -0400):
|
| You can do the following on either boxaa or boxbb, depending on which box
| you want to initiate the transfer.
| Doesn't matter which one is receiving or sending, it matters which one you
| want to initiate the job. Who's cron job calls the shots?
| On the box that is NOT initiating the job, lets say this is boxaa, do the
| following:
|
| # create 2 config files in /etc

The rsync configure script, like many others out there, defaults to
using /usr/local as a Prefix to /bin, thus installing its binaries in
/usr/local/bin.

This is "a good thing"(TM); I, for one, always see to it that /usr/local
is NOT in the root filesystem, thus saving lots of grief when updating
the Operating System.

Inexplicably, the configure script defaults to having rsyncd look for
rsyncd.conf in /etc (if it's not in the current working directory).
It's more logical to me that this file should reside in /usr/local/etc.

So I put it to you that you will increase happiness (and, mirabile
dictu, even decrease entropy?) if you would run rsync's configure script
with the option '--with-rsyncd-conf=/usr/local/etc'.

:-)

--
JP

----- Original Message -----
From: "Jean-Pierre Radley" <jpr@jpr.com>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Friday, August 26, 2005 6:42 PM
Subject: rsync configuration [Was: Re: Dying processes (inetd, cron,
syslogd, sshd)]


> Brian K. White typed (on Wed, Aug 24, 2005 at 04:28:31PM -0400):
> |
> | You can do the following on either boxaa or boxbb, depending on which
> box
> | you want to initiate the transfer.
> | Doesn't matter which one is receiving or sending, it matters which one
> you
> | want to initiate the job. Who's cron job calls the shots?
> | On the box that is NOT initiating the job, lets say this is boxaa, do
> the
> | following:
> |
> | # create 2 config files in /etc
>
> The rsync configure script, like many others out there, defaults to
> using /usr/local as a Prefix to /bin, thus installing its binaries in
> /usr/local/bin.
>
> This is "a good thing"(TM); I, for one, always see to it that /usr/local
> is NOT in the root filesystem, thus saving lots of grief when updating
> the Operating System.
>
> Inexplicably, the configure script defaults to having rsyncd look for
> rsyncd.conf in /etc (if it's not in the current working directory).
> It's more logical to me that this file should reside in /usr/local/etc.
>
> So I put it to you that you will increase happiness (and, mirabile
> dictu, even decrease entropy?) if you would run rsync's configure script
> with the option '--with-rsyncd-conf=/usr/local/etc'.

My opinion is it's philosophical issue with no best answer.
For example, your points are perfectly logical and valid.
However I feel there is more than one equally logical organization, just
with different reasons behind the logic.
For my part, I prefer not to have config files scattered in multiple places
around the filesystem any more than necessary.

Given that I don't think any particular location is more right than any
other in this case, I feel the least surprise is produced by not adding any
uneccessary ./configure options.
So the resulting binary is more likely to agree with more documents and
examples "out there".

It would seem that this argument should apply doubly to the binary, which I
do have to force into /usr/local. More, I also have to hack the
default --rsync-path
because when using rcmd and ssh, the path seen by the remote exec agent does
not include /usr/local/bin, so it can't run "rsync", and must be
"/usr/local/bin/rsync"
If I didn't touch anything rsync would install in /usr/bin or /bin
and --rsync-path would be "rsync", and that would work.

What can I say, I detest foreign substances in [/usr]/[s]bin but not in /etc

Maybe there is a logical reason for this actually. There may be both OS and
3rd party versions of the same program, you don't want your add-on binary to
be in danger of being replaced or removed by OS updates or rolling back OS
updates, yet you only want one config file to worry about.
(wget, curl, ssh, several other things that you used to always have to add
in /usr/local, are now shipped with the OS or in vendor supplied add-ons
like gnutools and gwxlibs)

Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

In article <04fa01c5aa9a$5bb41060$6b00000a@venti>,
Brian K. White <brian@aljex.com> wrote:

>----- Original Message -----
>From: "Jean-Pierre Radley" <jpr@jpr.com>
>Newsgroups: comp.unix.sco.misc
>To: <distro@jpr.com>
>Sent: Friday, August 26, 2005 6:42 PM
>Subject: rsync configuration [Was: Re: Dying processes (inetd, cron,
>syslogd, sshd)]
>

>> Brian K. White typed (on Wed, Aug 24, 2005 at 04:28:31PM
>> -0400): | | You can do the following on either boxaa or boxbb,
>> depending on which box | you want to initiate the transfer. |
>> Doesn't matter which one is receiving or sending, it matters
>> which one you | want to initiate the job. Who's cron job calls
>> the shots? | On the box that is NOT initiating the job, lets
>> say this is boxaa, do the | following:

>> | # create 2 config files in /etc

>> The rsync configure script, like many others out there, defaults to
>> using /usr/local as a Prefix to /bin, thus installing its binaries in
>> /usr/local/bin.

>> This is "a good thing"(TM); I, for one, always see to it that
>> /usr/local is NOT in the root filesystem, thus saving lots of
>> grief when updating the Operating System.

>> Inexplicably, the configure script defaults to having rsyncd
>> look for rsyncd.conf in /etc (if it's not in the current
>> working directory). It's more logical to me that this file
>> should reside in /usr/local/etc.

>> So I put it to you that you will increase happiness
>> (and, mirabile dictu, even decrease entropy?) if you
>> would run rsync's configure script with the option
>> '--with-rsyncd-conf=/usr/local/etc'.

>My opinion is it's philosophical issue with no best answer.
>For example, your points are perfectly logical and valid.

And followed to the letter by many of the free Unix like
implementations - such as FreeBSD.

>However I feel there is more than one equally logical
>organization, just with different reasons behind the logic. For
>my part, I prefer not to have config files scattered in multiple
>places around the filesystem any more than necessary.

In the xBSD land all programs added after the OS are part in
/usr/local which has a complete hierarch just as the regular OS
with directories under /usr/local being the typical etc, bin,
sbin, include, libdata, libexec, man, share, and var.

One nice thing about this is you can completely replace the OS
and never touch your locally installed files. So often in systems
with add-on programs sharing the same place with the OS it can
be a chinese-fire-drill [to use an old-phrase] trying to make sure
you keep what you want, and don't remove things that require a
re-install.

To my way of thinking, keeping add-ons and their ancilliary files
under /usr/local is the only logical choice - but then again I'm
not Spock or known for being completely logical.

>Given that I don't think any particular location is more right
>than any other in this case, I feel the least surprise is
>produced by not adding any uneccessary ./configure options.

Agree on that point.

....

>What can I say, I detest foreign substances in [/usr]/[s]bin but
>not in /etc

And having weaned myself from the Sys5 POV and back to my earliest
Unix learning, I've grown to really dislike systems that REQUIRE
/usr to have OS REQUIRED files. I like having /usr on a separate
partition. Which goes with the above comment about reinstalling,
where I can remake the / filesystem, and re-install, without ever
touching any add-on application.

Part of this POV is I'm lazy and hate to re-do something I've
already done.

>Maybe there is a logical reason for this actually. There may be
>both OS and 3rd party versions of the same program, you don't
>want your add-on binary to be in danger of being replaced or
>removed by OS updates or rolling back OS updates, yet you only
>want one config file to worry about. (wget, curl, ssh, several
>other things that you used to always have to add in /usr/local,
>are now shipped with the OS or in vendor supplied add-ons like
>gnutools and gwxlibs)

My points persactly :-)

Bill

--
Bill Vermillion - bv @ wjv . com

> In the xBSD land all programs added after the OS are part in
> /usr/local which has a complete hierarch just as the regular OS
> with directories under /usr/local being the typical etc, bin,
> sbin, include, libdata, libexec, man, share, and var.
>
> One nice thing about this is you can completely replace the OS
> and never touch your locally installed files. So often in systems
> with add-on programs sharing the same place with the OS it can
> be a chinese-fire-drill [to use an old-phrase] trying to make sure
> you keep what you want, and don't remove things that require a
> re-install.
>
> To my way of thinking, keeping add-ons and their ancilliary files
> under /usr/local is the only logical choice - but then again I'm
> not Spock or known for being completely logical.

/etc gets hand customized in freebsd just like any other.
The biggest difference is freebsd has mergemaster.

Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

In article <042601c5acd9$9d541060$6a1fa8c0@venti>,
Brian K. White <brian@aljex.com> wrote:
>> In the xBSD land all programs added after the OS are part in
>> /usr/local which has a complete hierarch just as the regular OS
>> with directories under /usr/local being the typical etc, bin,
>> sbin, include, libdata, libexec, man, share, and var.
>>
>> One nice thing about this is you can completely replace the OS
>> and never touch your locally installed files. So often in systems
>> with add-on programs sharing the same place with the OS it can
>> be a chinese-fire-drill [to use an old-phrase] trying to make sure
>> you keep what you want, and don't remove things that require a
>> re-install.

>> To my way of thinking, keeping add-ons and their ancilliary files
>> under /usr/local is the only logical choice - but then again I'm
>> not Spock or known for being completely logical.

>/etc gets hand customized in freebsd just like any other.
>The biggest difference is freebsd has mergemaster.

The ports tree uses variables PREFIX and LOCALBASE that is prepended
to the places that the application files go - eg etc, libexec,
lib. So they wind up going to /usr/local/etc and others.

You'll see this heavily used in /usr/ports/Mk

See 'man ports' and also see 'man make.conf'

It's not 'hand customized' but it is the default method
unless you override it. You can change these in /etc/make.conf

mergemaster has to do with taking the configuration files you
have in /etc and giving you the ability to merge new changes with
your old files so you don't have to re-enter a lot of data if you
did an upgrade. It really doesn't have a lot to do with
putting all the add-ons into /usr/local.

Bill
Bill


--
Bill Vermillion - bv @ wjv . com

----- Original Message -----
From: "Bill Vermillion" <bv@wjv.com>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Monday, August 29, 2005 7:45 PM
Subject: Re: rsync configuration [Was: Re: Dying processes (inetd, cron,
syslogd, sshd)]


> In article <042601c5acd9$9d541060$6a1fa8c0@venti>,
> Brian K. White <brian@aljex.com> wrote:
>>> In the xBSD land all programs added after the OS are part in
>>> /usr/local which has a complete hierarch just as the regular OS
>>> with directories under /usr/local being the typical etc, bin,
>>> sbin, include, libdata, libexec, man, share, and var.
>>>
>>> One nice thing about this is you can completely replace the OS
>>> and never touch your locally installed files. So often in systems
>>> with add-on programs sharing the same place with the OS it can
>>> be a chinese-fire-drill [to use an old-phrase] trying to make sure
>>> you keep what you want, and don't remove things that require a
>>> re-install.
>
>>> To my way of thinking, keeping add-ons and their ancilliary files
>>> under /usr/local is the only logical choice - but then again I'm
>>> not Spock or known for being completely logical.
>
>>/etc gets hand customized in freebsd just like any other.
>>The biggest difference is freebsd has mergemaster.
>
> The ports tree uses variables PREFIX and LOCALBASE that is prepended
> to the places that the application files go - eg etc, libexec,
> lib. So they wind up going to /usr/local/etc and others.
>
> You'll see this heavily used in /usr/ports/Mk
>
> See 'man ports' and also see 'man make.conf'
>
> It's not 'hand customized' but it is the default method
> unless you override it. You can change these in /etc/make.conf
>
> mergemaster has to do with taking the configuration files you
> have in /etc and giving you the ability to merge new changes with
> your old files so you don't have to re-enter a lot of data if you
> did an upgrade. It really doesn't have a lot to do with
> putting all the add-ons into /usr/local.

I know what mergemaster does and the sense behind /usr/local and all that.

My point was not that mergemaster had anything to do with /usr/local. It was
that, even on freebsd, there are things you customize per system in the main
/etc
which is a part of the base os, which means that at every update you face
the same 2 possible choices as any other OS:

1) lose* your changes during the update as the update overwrites them.
*OK it does usually back them up first such as the way sco's custom renames
things by appending pound signs and redhat's rpm appends .rpmorig

2) don't lose your changes, but break the apps whose configs syntax changed
but you didn't get a new matching default config during the update.

Except, the difference from any other os is, freebsd has mergemaster which
helps with the task of updating configs in-place _instead_ of having to
choose 1 or 2 above.

I forgot another thing too, some of the things you customize per box even in
/etc and /boot, the file you customize is actually one you add yourself or
that the update process specifically knows to leave alone, that a similar OS
supplied & updated file reads-in. So many things you edit in /etc and /boot
are actually safe in a update. This is just even more reason to feel that
/etc is not a bad place to put config files, including 3rd party add-ons.

Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!