Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Julian Elischer]

On 16/5/17 4:11 am, Ian Lepore wrote:

On Mon, 2017-05-15 at 12:22 -0700, John Baldwin wrote:

On Monday, May 15, 2017 11:43:21 AM Ian Lepore wrote:

On Mon, 2017-05-15 at 10:13 -0700, John Baldwin wrote:

On Saturday, May 13, 2017 10:39:15 AM Warner Losh wrote:






- It's really easy to screw up a mergemaster call if you
edit
the files, and install the stock version which removes the
edits.

Also, programmatically removing the entries means you have to
bake the metadata into etc/Makefile, which is already
complicated
enough as-is.

Why do you care about removing them at all? They are no-ops if
the
files don't exist. Why not just always install all these files
is
where I'm going with this...

I think this is actually the bigger question.  I think it is
perfectly
sensible to support conf.d/* files for ports to use and as a way
to
manage logs for application logs on an appliance, etc.  However,
this
shuffling is a bit of a merge nightmare for anyone using
mergemaster
or etcupdate, and the biggest cost is that newsyslog will create
a
one-line file in /var/log for entries with 'C'.


That's only a good argument for keeping the lines in the monolithic
file if those lines will be ignored when a file in the .conf.d
directory provides conflicting config.  Otherwise my embedded
product
that drops different rules for rotating /var/log/messages into
.conf.d
STILL has to programmatically edit the monolithic file to remove
the
standard rule(s).

Now you have to programmatically edit the file in
conf.d/foo.  However,
by this argument the monolithic conf file shouldn't even exist.  The
current approach is a half-way mix with the worst of both models it
seems.


Programmatically editing a single file containing only config for a
single component typically means just rewriting the entire file with
your new contents.  In particular, you don't need to attempt to
preserve other information, the format of which you may not even know,
including free-form comments and who knows what-else.


Also, _you_ could just splat an empty /etc/newsyslog.conf file on
your
appliance and create a bunch of conf.d/foo files if that is easier
for
you to use on an appliance.  The files we ship in a release aren't
really
tailored for an appliance (I've yet to see an appliance that doesn't
use
a FooBSD with local patches).  OTOH, the existing setup is probably
simpler to manage for an out-of-the-box install.

I'm also suprised you don't manage the newsyslog.conf file yourself
rather than trying to edit and merge in upstream changes?  That is, I
can see a few approaches:


You seem to be picturing some sort of etcupdate kind of thing.  I'm
more talking about a GUI or other config-management tool within an
embedded product that has to edit or rewrite configuration on the fly
based on user choices.

Of course, separate files does also simplify the update process, for
the most part.  If a new subsystem is added in a new freebsd release, I
have zero work to do to upgrade a system in the field if that new
subsystem just drops a new file into a .conf.d directory.  If it has
new entries in a monolithic file, then I do have to do some sort of
merge/edit operation.


1) Keep your real newsyslog.conf / syslogd.conf files in your
FooBSD's
VCS and when newsyslog.conf changes upstream you merge that in the
way you normally merge changes.

2) Move the "vendor" newsyslog.conf out entirely and install your own
versions of these files either as a monolithic assembled by config
management rules or a bunch of conf.d/foo files (here I would
probably
opt for separate files).

However, your approach doesn't seem to describe either of these since
this commit doesn't impact those work flows (if 1), you would have
already
made any local changes you need and if anything merging this commit
gives
you the kind of merge conflicts people will get on the next
mergemaster /
etcupdate for non-appliance boxes, or if 2) you ignore these files)


This seems to be an argument for everyone doing for themselves the
operation of splitting the distributed monolithic file into finer
grained files, and re-performing that operation (or at least the
analysis part of it) on every update.

We (Panzura) use the directory /etc/newsyslog.conf.d and have a separate
panzura.conf in there that we write out in one hit with all our log 
files in it.

we rewrite it all (from our internal metadata) if it needs to change.
We also have individual files for optional components that do their 
own logging,
so it is definitely important to us to have the ability to do the 
small files but I don't

really see a need to have a bunch of files for standard log files.
I think files should be grouped in "installable unit" atomicity.
and at this time the installable unit for the base system is the 
entire base unit..


Now when 'pkgbase' hist and we install our system from N separate pkg 
units the
argument will be different. It also needs to be decided what happens 
it multipl modules
use a 

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Mon, 2017-05-15 at 21:09 +, Alexey Dokuchaev wrote:
> On Mon, May 15, 2017 at 02:49:30PM -0600, Ian Lepore wrote:
> > 
> > ...
> > You acknowledge that the situation is different for ports, so does that
> > mean your objections go away when base becomes packaged and faces the
> > same installation and update issues that packaged ports do?  Because I
> > was under the impression that's coming pretty soon.
> The reason it is different for ports is because we cannot know up-front what
> software might user have installed and ergo what logs should be rotated by
> newsyslog(8).  For the base, we know these pieces (albeit packaging the base
> could probably benefit from the same generic approach, if we ever start to
> support 3rd-party "base" packages).
> 
> ./danfe
> 

The same is true of packaged base -- the user may have installed a
subset of the base system.  No need to configure ftp log stuff if ftp
didn't get installed.  Likewise for ntp, mail, news, everything that
has its own syslog facility code.

And really, while syslog config started this thread, most of what I've
been saying is more widely related to my initial comment:  moving from
monolithic to per-subsystem/object/whatever config files has been the
freebsd trend for a while.  That's not just for syslog rotation, that's
for rc config and jail config and pam (maybe where the trend started?)
and devd and periodic jobs and so on.

Most of these things support both a single file and individual files,
so nobody is forced to change all at once, but it does seem natural
that the existing base code evolve towards the newer mechanism.  When
it makes sense to still have the original file and only split out parts
of it to individual files, it might also make sense to drop a comment
into the original file to let old-timers know they should go looking in
the newer directory for additional entries.

Or it might makes sense to say: no half measures for a given
configuration scheme, if some items are to be split out to separate
files, then everything should be split, so that before the next major
release there is only a monolithic file, or a directory full of fine-
grained config, but not a mix.  I'm not advocating for that
necessarily, just thinking out loud really.

-- Ian

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Alexey Dokuchaev]

On Mon, May 15, 2017 at 08:28:53PM +, Alexey Dokuchaev wrote:
> On Mon, May 15, 2017 at 02:11:53PM -0600, Ian Lepore wrote:
> > ...
> > Sure, all us old-timers have the finger memory for editing rc.conf and
> > syslog.conf and so on, but how often do you crack open syslog.conf with
> > the plan of editing 12 different lines in it at once?
> 
> Actually I don't want to open it [newsyslog.conf] at all, and on desktop,
> where odd things are noticed quickly, default rotation is good enough.
> I might want to edit it on server to e.g. keep at least one year worth of
> logs, and when I do, I'd rather edit one file instead of half-dozen.

Thinking of it, it occurred to me that some simple inheritance mechanism
that would allow one to set (and centrally maintain) default "mode/count/
size/when/flags" in /etc/newsyslog.conf, without having to touch every
individual /etc/newsyslog.conf.d/foo.conf (while allowing per-log and per-
mode/count/size/when/flags override) could address most of the expressed
concerns so far.

I just hope it does not smell like sysd too much, because oh
boy, please no.

./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[John Baldwin]

On Monday, May 15, 2017 02:11:53 PM Ian Lepore wrote:
> On Mon, 2017-05-15 at 12:22 -0700, John Baldwin wrote:
> > Also, _you_ could just splat an empty /etc/newsyslog.conf file on
> > your
> > appliance and create a bunch of conf.d/foo files if that is easier
> > for
> > you to use on an appliance.  The files we ship in a release aren't
> > really
> > tailored for an appliance (I've yet to see an appliance that doesn't
> > use
> > a FooBSD with local patches).  OTOH, the existing setup is probably
> > simpler to manage for an out-of-the-box install.
> > 
> > I'm also suprised you don't manage the newsyslog.conf file yourself
> > rather than trying to edit and merge in upstream changes?  That is, I
> > can see a few approaches:
> > 
> 
> You seem to be picturing some sort of etcupdate kind of thing.  I'm
> more talking about a GUI or other config-management tool within an
> embedded product that has to edit or rewrite configuration on the fly
> based on user choices.
> 
> Of course, separate files does also simplify the update process, for
> the most part.  If a new subsystem is added in a new freebsd release, I
> have zero work to do to upgrade a system in the field if that new
> subsystem just drops a new file into a .conf.d directory.  If it has
> new entries in a monolithic file, then I do have to do some sort of
> merge/edit operation.

But given that the new system now supports both approaches, why wouldn't
you always split it up in your product?

> > 1) Keep your real newsyslog.conf / syslogd.conf files in your
> > FooBSD's
> >VCS and when newsyslog.conf changes upstream you merge that in the
> >way you normally merge changes.
> > 
> > 2) Move the "vendor" newsyslog.conf out entirely and install your own
> >versions of these files either as a monolithic assembled by config
> >management rules or a bunch of conf.d/foo files (here I would
> > probably
> >opt for separate files).
> > 
> > However, your approach doesn't seem to describe either of these since
> > this commit doesn't impact those work flows (if 1), you would have
> > already
> > made any local changes you need and if anything merging this commit
> > gives
> > you the kind of merge conflicts people will get on the next
> > mergemaster /
> > etcupdate for non-appliance boxes, or if 2) you ignore these files)
> > 
> 
> This seems to be an argument for everyone doing for themselves the
> operation of splitting the distributed monolithic file into finer
> grained files, and re-performing that operation (or at least the
> analysis part of it) on every update.

s/everbody/appliance vendors/.  Not everyone is your use case (nor mine).

That said, I would think that the current approach is still the worst
of both worlds for you.  Now you have a single file you need to edit
in some cases and in other cases you generate the single foo.conf
file.  I don't see why you wouldn't always want to split things up in
your product and on the rare chance that the big file changes upstream
you alter the default broken-out file in your FooBSD (especially given
how rarely these files change).

> In general a lot of this feels like "I only needed 6 big config files
> to control my whole system in 1988, and so I should only need those
> same 6 files now."  Sure, all us old-timers have the finger memory for
> editing rc.conf and syslog.conf and so on, but how often do you crack
> open syslog.conf with the plan of editing 12 different lines in it at
> once?  Because the main objection to .conf.d directories seems to be
> that there are more files to edit, and that just doesn't feel like a
> big problem in actual daily use.

To be clear, I _don't_ object to conf.d directories and I'm happy to
have the tools support both types of configurations.  I object to
employing a half-way mix of both styles in a way that breaks POLA and
causes merge headaches for existing users that are applying these
changes as upgrades to existing systems.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Alexey Dokuchaev]

On Mon, May 15, 2017 at 02:49:30PM -0600, Ian Lepore wrote:
> ...
> You acknowledge that the situation is different for ports, so does that
> mean your objections go away when base becomes packaged and faces the
> same installation and update issues that packaged ports do?  Because I
> was under the impression that's coming pretty soon.

The reason it is different for ports is because we cannot know up-front what
software might user have installed and ergo what logs should be rotated by
newsyslog(8).  For the base, we know these pieces (albeit packaging the base
could probably benefit from the same generic approach, if we ever start to
support 3rd-party "base" packages).

./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Mon, 2017-05-15 at 20:28 +, Alexey Dokuchaev wrote:
> On Mon, May 15, 2017 at 02:11:53PM -0600, Ian Lepore wrote:
> > 
> > ...
> > In general a lot of this feels like "I only needed 6 big config
> > files
> > to control my whole system in 1988, and so I should only need those
> > same 6 files now."
> Yup; doesn't it feel good?  (That's one of our selling points BTW.)
> 
> > 
> > Sure, all us old-timers have the finger memory for editing rc.conf
> > and
> > syslog.conf and so on, but how often do you crack open syslog.conf
> > with
> > the plan of editing 12 different lines in it at once?
> Actually I don't want to open it [newsyslog.conf] at all, and on
> desktop,
> where odd things are noticed quickly, default rotation is good
> enough.
> I might want to edit it on server to e.g. keep at least one year
> worth of
> logs, and when I do, I'd rather edit one file instead of half-dozen.
> 
> > 
> > Because the main objection to .conf.d directories seems to be that
> > there are more files to edit, and that just doesn't feel like a big
> > problem in actual daily use.
> Well, it kind of is.  Keeping in mind "same 6 files" is a big helper;
> for the base you can be sure you won't forget anything accidentally.
> It is not that easy for ports for obvious reasons, but then again: we
> are talking about the base only here.
> 

What you're talking about is how YOU view and use base.  That's fine,
except that obviously it's only a tiny subset of how all freebsd users
view and use base.

Besides how I view things as someone who has to create and maintain
complex embedded systems with freebsd, as a simple user of freebsd I
would much prefer to edit syslog.conf.d/mail than search around in a
big syslog.conf file for lines pertaining to mail logging.

You acknowledge that the situation is different for ports, so does that
mean your objections go away when base becomes packaged and faces the
same installation and update issues that packaged ports do?  Because I
was under the impression that's coming pretty soon.

-- Ian

> ./danfe
> 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Alexey Dokuchaev]

On Mon, May 15, 2017 at 02:11:53PM -0600, Ian Lepore wrote:
> ...
> In general a lot of this feels like "I only needed 6 big config files
> to control my whole system in 1988, and so I should only need those
> same 6 files now."

Yup; doesn't it feel good?  (That's one of our selling points BTW.)

> Sure, all us old-timers have the finger memory for editing rc.conf and
> syslog.conf and so on, but how often do you crack open syslog.conf with
> the plan of editing 12 different lines in it at once?

Actually I don't want to open it [newsyslog.conf] at all, and on desktop,
where odd things are noticed quickly, default rotation is good enough.
I might want to edit it on server to e.g. keep at least one year worth of
logs, and when I do, I'd rather edit one file instead of half-dozen.

> Because the main objection to .conf.d directories seems to be that
> there are more files to edit, and that just doesn't feel like a big
> problem in actual daily use.

Well, it kind of is.  Keeping in mind "same 6 files" is a big helper;
for the base you can be sure you won't forget anything accidentally.
It is not that easy for ports for obvious reasons, but then again: we
are talking about the base only here.

./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Mon, 2017-05-15 at 14:11 -0600, Ian Lepore wrote:
> On Mon, 2017-05-15 at 12:22 -0700, John Baldwin wrote:
> > 
> > On Monday, May 15, 2017 11:43:21 AM Ian Lepore wrote:
> > > 
> > > 
[...]
> > 
> > Also, _you_ could just splat an empty /etc/newsyslog.conf file on
> > your
> > appliance and create a bunch of conf.d/foo files if that is easier
> > for
> > you to use on an appliance.  The files we ship in a release aren't
> > really
> > tailored for an appliance (I've yet to see an appliance that doesn't
> > use
> > a FooBSD with local patches).  OTOH, the existing setup is probably
> > simpler to manage for an out-of-the-box install.
> > 
> > I'm also suprised you don't manage the newsyslog.conf file yourself
> > rather than trying to edit and merge in upstream changes?  That is, I
> > can see a few approaches:
> > 
> You seem to be picturing some sort of etcupdate kind of thing.  I'm
> more talking about a GUI or other config-management tool within an
> embedded product that has to edit or rewrite configuration on the fly
> based on user choices.
> 
> Of course, separate files does also simplify the update process, for
> the most part.  If a new subsystem is added in a new freebsd release, I
> have zero work to do to upgrade a system in the field if that new
> subsystem just drops a new file into a .conf.d directory.  If it has
> new entries in a monolithic file, then I do have to do some sort of
> merge/edit operation.
> 

And just to be clear here, I'm talking about running some kind of
merge/edit on the live system being updated in the field, not as part
of importing a newer freebsd snapshot into our VCS.

-- Ian

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Mon, 2017-05-15 at 12:22 -0700, John Baldwin wrote:
> On Monday, May 15, 2017 11:43:21 AM Ian Lepore wrote:
> > 
> > On Mon, 2017-05-15 at 10:13 -0700, John Baldwin wrote:
> > > 
> > > On Saturday, May 13, 2017 10:39:15 AM Warner Losh wrote:
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > - It's really easy to screw up a mergemaster call if you
> > > > > > edit
> > > > > > the files, and install the stock version which removes the
> > > > > > edits.
> > > > > Also, programmatically removing the entries means you have to
> > > > > bake the metadata into etc/Makefile, which is already
> > > > > complicated
> > > > > enough as-is.
> > > > Why do you care about removing them at all? They are no-ops if
> > > > the
> > > > files don't exist. Why not just always install all these files
> > > > is
> > > > where I'm going with this...
> > > I think this is actually the bigger question.  I think it is
> > > perfectly
> > > sensible to support conf.d/* files for ports to use and as a way
> > > to
> > > manage logs for application logs on an appliance, etc.  However,
> > > this
> > > shuffling is a bit of a merge nightmare for anyone using
> > > mergemaster
> > > or etcupdate, and the biggest cost is that newsyslog will create
> > > a
> > > one-line file in /var/log for entries with 'C'.
> > > 
> > That's only a good argument for keeping the lines in the monolithic
> > file if those lines will be ignored when a file in the .conf.d
> > directory provides conflicting config.  Otherwise my embedded
> > product
> > that drops different rules for rotating /var/log/messages into
> > .conf.d
> > STILL has to programmatically edit the monolithic file to remove
> > the
> > standard rule(s).
> Now you have to programmatically edit the file in
> conf.d/foo.  However,
> by this argument the monolithic conf file shouldn't even exist.  The
> current approach is a half-way mix with the worst of both models it
> seems.
> 

Programmatically editing a single file containing only config for a
single component typically means just rewriting the entire file with
your new contents.  In particular, you don't need to attempt to
preserve other information, the format of which you may not even know,
including free-form comments and who knows what-else.

> Also, _you_ could just splat an empty /etc/newsyslog.conf file on
> your
> appliance and create a bunch of conf.d/foo files if that is easier
> for
> you to use on an appliance.  The files we ship in a release aren't
> really
> tailored for an appliance (I've yet to see an appliance that doesn't
> use
> a FooBSD with local patches).  OTOH, the existing setup is probably
> simpler to manage for an out-of-the-box install.
> 
> I'm also suprised you don't manage the newsyslog.conf file yourself
> rather than trying to edit and merge in upstream changes?  That is, I
> can see a few approaches:
> 

You seem to be picturing some sort of etcupdate kind of thing.  I'm
more talking about a GUI or other config-management tool within an
embedded product that has to edit or rewrite configuration on the fly
based on user choices.

Of course, separate files does also simplify the update process, for
the most part.  If a new subsystem is added in a new freebsd release, I
have zero work to do to upgrade a system in the field if that new
subsystem just drops a new file into a .conf.d directory.  If it has
new entries in a monolithic file, then I do have to do some sort of
merge/edit operation.

> 1) Keep your real newsyslog.conf / syslogd.conf files in your
> FooBSD's
>    VCS and when newsyslog.conf changes upstream you merge that in the
>    way you normally merge changes.
> 
> 2) Move the "vendor" newsyslog.conf out entirely and install your own
>    versions of these files either as a monolithic assembled by config
>    management rules or a bunch of conf.d/foo files (here I would
> probably
>    opt for separate files).
> 
> However, your approach doesn't seem to describe either of these since
> this commit doesn't impact those work flows (if 1), you would have
> already
> made any local changes you need and if anything merging this commit
> gives
> you the kind of merge conflicts people will get on the next
> mergemaster /
> etcupdate for non-appliance boxes, or if 2) you ignore these files)
> 

This seems to be an argument for everyone doing for themselves the
operation of splitting the distributed monolithic file into finer
grained files, and re-performing that operation (or at least the
analysis part of it) on every update.

In general a lot of this feels like "I only needed 6 big config files
to control my whole system in 1988, and so I should only need those
same 6 files now."  Sure, all us old-timers have the finger memory for
editing rc.conf and syslog.conf and so on, but how often do you crack
open syslog.conf with the plan of editing 12 different lines in it at
once?  Because the main objection to .conf.d directories seems to be
that there are more files to 

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[John Baldwin]

On Monday, May 15, 2017 11:43:21 AM Ian Lepore wrote:
> On Mon, 2017-05-15 at 10:13 -0700, John Baldwin wrote:
> > On Saturday, May 13, 2017 10:39:15 AM Warner Losh wrote:
> > > 
> > > > 
> > > > > 
> > > > > - It's really easy to screw up a mergemaster call if you edit
> > > > > the files, and install the stock version which removes the
> > > > > edits.
> > > > Also, programmatically removing the entries means you have to
> > > > bake the metadata into etc/Makefile, which is already complicated
> > > > enough as-is.
> > > Why do you care about removing them at all? They are no-ops if the
> > > files don't exist. Why not just always install all these files is
> > > where I'm going with this...
> > I think this is actually the bigger question.  I think it is
> > perfectly
> > sensible to support conf.d/* files for ports to use and as a way to
> > manage logs for application logs on an appliance, etc.  However, this
> > shuffling is a bit of a merge nightmare for anyone using mergemaster
> > or etcupdate, and the biggest cost is that newsyslog will create a
> > one-line file in /var/log for entries with 'C'.
> > 
> 
> That's only a good argument for keeping the lines in the monolithic
> file if those lines will be ignored when a file in the .conf.d
> directory provides conflicting config.  Otherwise my embedded product
> that drops different rules for rotating /var/log/messages into .conf.d
> STILL has to programmatically edit the monolithic file to remove the
> standard rule(s).

Now you have to programmatically edit the file in conf.d/foo.  However,
by this argument the monolithic conf file shouldn't even exist.  The
current approach is a half-way mix with the worst of both models it
seems.

Also, _you_ could just splat an empty /etc/newsyslog.conf file on your
appliance and create a bunch of conf.d/foo files if that is easier for
you to use on an appliance.  The files we ship in a release aren't really
tailored for an appliance (I've yet to see an appliance that doesn't use
a FooBSD with local patches).  OTOH, the existing setup is probably
simpler to manage for an out-of-the-box install.

I'm also suprised you don't manage the newsyslog.conf file yourself
rather than trying to edit and merge in upstream changes?  That is, I
can see a few approaches:

1) Keep your real newsyslog.conf / syslogd.conf files in your FooBSD's
   VCS and when newsyslog.conf changes upstream you merge that in the
   way you normally merge changes.

2) Move the "vendor" newsyslog.conf out entirely and install your own
   versions of these files either as a monolithic assembled by config
   management rules or a bunch of conf.d/foo files (here I would probably
   opt for separate files).

However, your approach doesn't seem to describe either of these since
this commit doesn't impact those work flows (if 1), you would have already
made any local changes you need and if anything merging this commit gives
you the kind of merge conflicts people will get on the next mergemaster /
etcupdate for non-appliance boxes, or if 2) you ignore these files)

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Mon, 2017-05-15 at 11:24 -0700, Ngie Cooper (yaneurabeya) wrote:
> > 
> > On May 15, 2017, at 10:47, Ngie Cooper (yaneurabeya)  > mail.com> wrote:
> > 
> > 
> > > 
> > > On May 15, 2017, at 10:43, Ian Lepore  wrote:
> > …
> > 
> > > 
> > > That's only a good argument for keeping the lines in the
> > > monolithic
> > > file if those lines will be ignored when a file in the .conf.d
> > > directory provides conflicting config.  Otherwise my embedded
> > > product
> > > that drops different rules for rotating /var/log/messages into
> > > .conf.d
> > > STILL has to programmatically edit the monolithic file to remove
> > > the
> > > standard rule(s).
> > Bingo. This is part of the reason why I did this, apart from
> > being selfish in not wanting to handle a handful of unnecessary
> > entries in newsyslog/syslogd on all of my systems where I set these
> > knobs to no.
> > Literally all I did was `dd+p` in vim in the new files. I didn’t
> > add or subtract any overall entries.
> And for context, we (Isilon) run newsyslog more frequently than
> upstream (sometimes every couple minutes, sometimes multiple times an
> hour/day), attributing to unnecessary creation and modification of
> log files (like this) that we (Isilon) don’t care about at all, which
> causes other potential issues with root media wear, potential for
> filesystem corruption, reduced number of available inodes/space
> because it allocates at least the frag size for a file, etc.
> 

We also run log rotation frequently (every 5 minutes) on our embedded
systems.  That was super-important back when we logged to a ram
filesystem, then newsyslog would rotate and compress from there to
sdcard.  Now we just log to sdcard because when something goes wrong
it's almost always the end of the log that has the clues (unless
something triggers runaway log spewage) and we often lost it.

A local modification we still apply to our syslogd allows you to
specify in syslog.conf that for any given file, syslogd itself should
limit the size of that file if the rotation doesn't take care of it
soon enough.  That was important to prevent filling up a ram filesystem
with runaway logging.  Now it's a feature we don't use much, but before
I throw it overboard I thought I'd mention it here in case others have
any use for it...

The way the feature worked was you could put at the end of a line in
syslog.conf "R K" -- the 'R' had a historical meaning that's now
lost, so we bacronymed it to mean "Recycle" -- when the log grows to
K in size, the last 32K of the file becomes a circular buffer that
continually gets rewritten until a normal file rotation happens.  If
something triggers runaway logging, the hope is that that event got
captured somewhere before the final 32k of the file, so you still have
some clues for postmortem analysis.

-- Ian

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Bryan Drewery]

On 5/12/2017 8:10 PM, Ngie Cooper wrote:
> Author: ngie
> Date: Sat May 13 03:10:50 2017
> New Revision: 318250
> URL: https://svnweb.freebsd.org/changeset/base/318250
> 
> Log:
>   Handle the logfiles in newsyslog and syslogd conditionally, based on
>   src.conf(5) knobs
>   
>   This will allow consumers of FreeBSD to use the unmodified configuration
>   files out of the box more than previously.
>   
>   Both newsyslog.conf and syslog.conf:
>   - /var/log/lpd-errs (MK_LPR != no)
>   - /var/log/ppp.log (MK_PPP != no)
>   - /var/log/xferlog (MK_FTP != no)
>   
>   newsyslog.conf:
>   - /var/log/amd.log (MK_AMD != no)
>   - /var/log/pflog (MK_PF != no)
>   - /var/log/sendmail.st (MK_SENDMAIL != no)
>   
>   MFC after:  3 weeks
>   Sponsored by:   Dell EMC Isilon
> 
> Added:
>   head/etc/newsyslog.conf.d/amd.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/ftp.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/lpr.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/pf.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/ppp.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/sendmail.conf   (contents, props changed)
>   head/etc/syslog.d/
>   head/etc/syslog.d/Makefile   (contents, props changed)
>   head/etc/syslog.d/ftp.conf   (contents, props changed)
>   head/etc/syslog.d/lpr.conf   (contents, props changed)
>   head/etc/syslog.d/ppp.conf   (contents, props changed)
> Modified:
>   head/etc/Makefile
>   head/etc/newsyslog.conf
>   head/etc/newsyslog.conf.d/Makefile
>   head/etc/syslog.conf
>   head/tools/build/mk/OptionalObsoleteFiles.inc

+1

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 10:47, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On May 15, 2017, at 10:43, Ian Lepore  wrote:
> 
> …
> 
>> That's only a good argument for keeping the lines in the monolithic
>> file if those lines will be ignored when a file in the .conf.d
>> directory provides conflicting config.  Otherwise my embedded product
>> that drops different rules for rotating /var/log/messages into .conf.d
>> STILL has to programmatically edit the monolithic file to remove the
>> standard rule(s).
> 
>   Bingo. This is part of the reason why I did this, apart from being 
> selfish in not wanting to handle a handful of unnecessary entries in 
> newsyslog/syslogd on all of my systems where I set these knobs to no.
> Literally all I did was `dd+p` in vim in the new files. I didn’t add or 
> subtract any overall entries.

And for context, we (Isilon) run newsyslog more frequently than upstream 
(sometimes every couple minutes, sometimes multiple times an hour/day), 
attributing to unnecessary creation and modification of log files (like this) 
that we (Isilon) don’t care about at all, which causes other potential issues 
with root media wear, potential for filesystem corruption, reduced number of 
available inodes/space because it allocates at least the frag size for a file, 
etc.

Plus with the number of entries we have in syslog.conf (an order of magnitude 
larger than upstream), having to walk a linked list to evaluate how to handle 
messages when putting them out in log files does tend to add up with all of the 
logging we do on our appliances (which is considerably more chatty than I’ve 
seen other appliance vendors that I’ve worked for).

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 10:43, Ian Lepore  wrote:

…

> That's only a good argument for keeping the lines in the monolithic
> file if those lines will be ignored when a file in the .conf.d
> directory provides conflicting config.  Otherwise my embedded product
> that drops different rules for rotating /var/log/messages into .conf.d
> STILL has to programmatically edit the monolithic file to remove the
> standard rule(s).

Bingo. This is part of the reason why I did this, apart from being 
selfish in not wanting to handle a handful of unnecessary entries in 
newsyslog/syslogd on all of my systems where I set these knobs to no.
Literally all I did was `dd+p` in vim in the new files. I didn’t add or 
subtract any overall entries.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Mon, 2017-05-15 at 10:13 -0700, John Baldwin wrote:
> On Saturday, May 13, 2017 10:39:15 AM Warner Losh wrote:
> > 
> > > 
> > > > 
> > > > - It's really easy to screw up a mergemaster call if you edit
> > > > the files, and install the stock version which removes the
> > > > edits.
> > > Also, programmatically removing the entries means you have to
> > > bake the metadata into etc/Makefile, which is already complicated
> > > enough as-is.
> > Why do you care about removing them at all? They are no-ops if the
> > files don't exist. Why not just always install all these files is
> > where I'm going with this...
> I think this is actually the bigger question.  I think it is
> perfectly
> sensible to support conf.d/* files for ports to use and as a way to
> manage logs for application logs on an appliance, etc.  However, this
> shuffling is a bit of a merge nightmare for anyone using mergemaster
> or etcupdate, and the biggest cost is that newsyslog will create a
> one-line file in /var/log for entries with 'C'.
> 

That's only a good argument for keeping the lines in the monolithic
file if those lines will be ignored when a file in the .conf.d
directory provides conflicting config.  Otherwise my embedded product
that drops different rules for rotating /var/log/messages into .conf.d
STILL has to programmatically edit the monolithic file to remove the
standard rule(s).

-- Ian

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[John Baldwin]

On Saturday, May 13, 2017 10:39:15 AM Warner Losh wrote:
> >> - It's really easy to screw up a mergemaster call if you edit the files, 
> >> and install the stock version which removes the edits.
> >
> > Also, programmatically removing the entries means you have to bake the 
> > metadata into etc/Makefile, which is already complicated enough as-is.
> 
> Why do you care about removing them at all? They are no-ops if the
> files don't exist. Why not just always install all these files is
> where I'm going with this...

I think this is actually the bigger question.  I think it is perfectly
sensible to support conf.d/* files for ports to use and as a way to
manage logs for application logs on an appliance, etc.  However, this
shuffling is a bit of a merge nightmare for anyone using mergemaster
or etcupdate, and the biggest cost is that newsyslog will create a
one-line file in /var/log for entries with 'C'.

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Nikolai Lifanov]

On 05/13/2017 13:21, Ngie Cooper (yaneurabeya) wrote:
> Even ansible/chef/puppet would have to bake the configuration removal logic 
> into its template files, which seems like a pain for folks (and the same 
> logic would need to be implemented multiple times instead of once).

Having to template one .conf file couples not necessarily related config
modules together and it's *a lot* more performant to conditionally
install and remove config snippets in .d/ than to expand a template.

The separation matters when separate people write separate configuration
modules and the performance matters when deciding on frequency of config
runs.

- Nikolai



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ngie Cooper (yaneurabeya)]

> On May 13, 2017, at 9:51 AM, Alexey Dokuchaev  wrote:
> 
> On Sat, May 13, 2017 at 10:24:20AM -0600, Ian Lepore wrote:
>> ...
>> The evolution for years has been away from monolithic config files
>> containing a mashup of values for unrelated subsystems and towards
>> .conf.d directories containing many single-subject files.
> 
> This "evolution" had probably originated in people's minds who know little
> about software development and maintenance.  And FWIW, newsyslog files are
> not about "unrelated subsystems", it's about one subsystem responsible for
> log rotation.

This hasn’t really changed with moving to .conf.d. A single subsystem is 
managing a series of modular config files, instead of a single config file. I 
firmly believe that this was the right general approach to go.

> Speaking of "unrelated subsystems", /etc/rc.conf is a living manifestation
> of how "unrelated subsystems" can be configured in a single file and, mind
> you, everyone is being quite happy about it.

… except people have to bake in defaults in rc.d scripts for whether or not 
services should be disabled because they can’t put apache defaults in 
/etc/rc.conf . /etc/rc.conf isn’t managed via etcupdate or mergemaster, so I 
think this comparison is like apples to oranges.

>> The monolithic files are difficult to edit
> 
> Quite on the contrary: monolithic files are much easier to edit and keep
> track of by a human being (system operator).

I strongly disagree, having seen multiple configuration files a couple hundred 
lines long. It gets messy and for those who don’t understand how 
syslogd/newsyslog works (inevitably, these people are the ones that get charged 
with implementing daemons, and this is one of the pieces that needs to be done).

>> and otherwise manage programmatically, and especially difficult to manage
>> in terms of software packaging and software updates.
> 
> Please don't mix "difficult to edit" and "manage programmatically".  As I
> have said, having support for "include *.conf.d" makes sense for 3rd-party
> software (read: ports), but has little need for the base, and IMHO brings
> more maintenance burden than any benefit.

Can you please provide an example of how it’s more burdensome going to .conf.d? 
Personally, I think it’s a whole lot easier doing `rm -f 
/etc/newsyslog.d/amd.conf`, than it is to open up the file and edit out the amd 
entries, or invoke sed/something else to do the same thing.

Even ansible/chef/puppet would have to bake the configuration removal logic 
into its template files, which seems like a pain for folks (and the same logic 
would need to be implemented multiple times instead of once).

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ngie Cooper (yaneurabeya)]

> On May 13, 2017, at 9:39 AM, Warner Losh  wrote:
> 
> On Sat, May 13, 2017 at 10:32 AM, Ngie Cooper  > wrote:
>> 
>>> On May 13, 2017, at 09:29, Ngie Cooper  wrote:
>>> 
>>> On May 13, 2017, at 08:37, Rodney W. Grimes 
>>>  wrote:
>>> 
> Author: ngie
> Date: Sat May 13 03:10:50 2017
> New Revision: 318250
> URL: https://svnweb.freebsd.org/changeset/base/318250
> 
> Log:
> Handle the logfiles in newsyslog and syslogd conditionally, based on
> src.conf(5) knobs
> 
> This will allow consumers of FreeBSD to use the unmodified configuration
> files out of the box more than previously.
 
 What about simply generating proper newsyslog.conf and syslog.conf based
 on the the MK_ values rather than change the visible administration
 interface that has finger memory, ansible, and puppet support?
>>> 
>>> - My employer doesn't use puppet on its appliances.
>>> - Files snapshotted in time bitrot (which was the case with our configs, 
>>> which is part of the reason behind this change.
> 
> couldn't you have an Isilion config file in the appropriate directory
> instead? And use the default newsyslog / syslog config files?

I’m not sure I’m in disagreement with this statement, but the fact is that 
there are a handful of config files, about 200 lines each, which drive 
newsyslog/syslogd on OneFS, with a fair amount of duplication. I’m trying to 
simplify the mess I’m presented with at work, one bit at a time.

>>> - It's really easy to screw up a mergemaster call if you edit the files, 
>>> and install the stock version which removes the edits.
>> 
>> Also, programmatically removing the entries means you have to bake the 
>> metadata into etc/Makefile, which is already complicated enough as-is.
> 
> Why do you care about removing them at all? They are no-ops if the
> files don't exist. Why not just always install all these files is
> where I'm going with this…

I don’t follow. Could you please restate this paragraph?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Alexey Dokuchaev]

On Sat, May 13, 2017 at 10:24:20AM -0600, Ian Lepore wrote:
> ...
> The evolution for years has been away from monolithic config files
> containing a mashup of values for unrelated subsystems and towards
> .conf.d directories containing many single-subject files.

This "evolution" had probably originated in people's minds who know little
about software development and maintenance.  And FWIW, newsyslog files are
not about "unrelated subsystems", it's about one subsystem responsible for
log rotation.

Speaking of "unrelated subsystems", /etc/rc.conf is a living manifestation
of how "unrelated subsystems" can be configured in a single file and, mind
you, everyone is being quite happy about it.

> The monolithic files are difficult to edit

Quite on the contrary: monolithic files are much easier to edit and keep
track of by a human being (system operator).

> and otherwise manage programmatically, and especially difficult to manage
> in terms of software packaging and software updates.

Please don't mix "difficult to edit" and "manage programmatically".  As I
have said, having support for "include *.conf.d" makes sense for 3rd-party
software (read: ports), but has little need for the base, and IMHO brings
more maintenance burden than any benefit.

./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Warner Losh]

On Sat, May 13, 2017 at 10:32 AM, Ngie Cooper  wrote:
>
>> On May 13, 2017, at 09:29, Ngie Cooper  wrote:
>>
>> On May 13, 2017, at 08:37, Rodney W. Grimes  
>> wrote:
>>
 Author: ngie
 Date: Sat May 13 03:10:50 2017
 New Revision: 318250
 URL: https://svnweb.freebsd.org/changeset/base/318250

 Log:
 Handle the logfiles in newsyslog and syslogd conditionally, based on
 src.conf(5) knobs

 This will allow consumers of FreeBSD to use the unmodified configuration
 files out of the box more than previously.
>>>
>>> What about simply generating proper newsyslog.conf and syslog.conf based
>>> on the the MK_ values rather than change the visible administration
>>> interface that has finger memory, ansible, and puppet support?
>>
>> - My employer doesn't use puppet on its appliances.
>> - Files snapshotted in time bitrot (which was the case with our configs, 
>> which is part of the reason behind this change.

couldn't you have an Isilion config file in the appropriate directory
instead? And use the default newsyslog / syslog config files?

>> - It's really easy to screw up a mergemaster call if you edit the files, and 
>> install the stock version which removes the edits.
>
> Also, programmatically removing the entries means you have to bake the 
> metadata into etc/Makefile, which is already complicated enough as-is.

Why do you care about removing them at all? They are no-ops if the
files don't exist. Why not just always install all these files is
where I'm going with this...

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ngie Cooper]

> On May 13, 2017, at 09:29, Ngie Cooper  wrote:
> 
> On May 13, 2017, at 08:37, Rodney W. Grimes  
> wrote:
> 
>>> Author: ngie
>>> Date: Sat May 13 03:10:50 2017
>>> New Revision: 318250
>>> URL: https://svnweb.freebsd.org/changeset/base/318250
>>> 
>>> Log:
>>> Handle the logfiles in newsyslog and syslogd conditionally, based on
>>> src.conf(5) knobs
>>> 
>>> This will allow consumers of FreeBSD to use the unmodified configuration
>>> files out of the box more than previously.
>> 
>> What about simply generating proper newsyslog.conf and syslog.conf based
>> on the the MK_ values rather than change the visible administration
>> interface that has finger memory, ansible, and puppet support?
> 
> - My employer doesn't use puppet on its appliances.
> - Files snapshotted in time bitrot (which was the case with our configs, 
> which is part of the reason behind this change.
> - It's really easy to screw up a mergemaster call if you edit the files, and 
> install the stock version which removes the edits.

Also, programmatically removing the entries means you have to bake the metadata 
into etc/Makefile, which is already complicated enough as-is.
Thanks,
-Ngie
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ngie Cooper]

On May 13, 2017, at 08:37, Rodney W. Grimes  
wrote:

>> Author: ngie
>> Date: Sat May 13 03:10:50 2017
>> New Revision: 318250
>> URL: https://svnweb.freebsd.org/changeset/base/318250
>> 
>> Log:
>>  Handle the logfiles in newsyslog and syslogd conditionally, based on
>>  src.conf(5) knobs
>> 
>>  This will allow consumers of FreeBSD to use the unmodified configuration
>>  files out of the box more than previously.
> 
> What about simply generating proper newsyslog.conf and syslog.conf based
> on the the MK_ values rather than change the visible administration
> interface that has finger memory, ansible, and puppet support?

- My employer doesn't use puppet on its appliances.
- Files snapshotted in time bitrot (which was the case with our configs, which 
is part of the reason behind this change.
- It's really easy to screw up a mergemaster call if you edit the files, and 
install the stock version which removes the edits.
Thanks,
-Ngie
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Alexey Dokuchaev]

On Sat, May 13, 2017 at 08:37:42AM -0700, Rodney W. Grimes wrote:
> > New Revision: 318250
> > URL: https://svnweb.freebsd.org/changeset/base/318250
> > 
> > Log:
> >   Handle the logfiles in newsyslog and syslogd conditionally, based on
> >   src.conf(5) knobs
> >   
> >   This will allow consumers of FreeBSD to use the unmodified configuration
> >   files out of the box more than previously.
> 
> What about simply generating proper newsyslog.conf and syslog.conf based
> on the the MK_ values rather than change the visible administration
> interface that has finger memory, ansible, and puppet support?

+1.  I've always loved FreeBSD for its simplicity, and having to know/care
about one or two config files is one of it; these *.d populated directories
smell like Linux too much.

I understand the reason behind supporting those for ports, but please don't
plague our base with this one-line config files scattered around idiocy.

./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Sat, 2017-05-13 at 08:37 -0700, Rodney W. Grimes wrote:
> > 
> > Author: ngie
> > Date: Sat May 13 03:10:50 2017
> > New Revision: 318250
> > URL: https://svnweb.freebsd.org/changeset/base/318250
> > 
> > Log:
> >   Handle the logfiles in newsyslog and syslogd conditionally, based on
> >   src.conf(5) knobs
> >   
> >   This will allow consumers of FreeBSD to use the unmodified configuration
> >   files out of the box more than previously.
> What about simply generating proper newsyslog.conf and syslog.conf based
> on the the MK_ values rather than change the visible administration
> interface that has finger memory, ansible, and puppet support?
> 

The evolution for years has been away from monolithic config files
containing a mashup of values for unrelated subsystems and towards
.conf.d directories containing many single-subject files.  The
monolithic files are difficult to edit and otherwise manage
programmatically, and especially difficult to manage in terms of
software packaging and software updates.

-- Ian

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Rodney W. Grimes]

> Author: ngie
> Date: Sat May 13 03:10:50 2017
> New Revision: 318250
> URL: https://svnweb.freebsd.org/changeset/base/318250
> 
> Log:
>   Handle the logfiles in newsyslog and syslogd conditionally, based on
>   src.conf(5) knobs
>   
>   This will allow consumers of FreeBSD to use the unmodified configuration
>   files out of the box more than previously.

What about simply generating proper newsyslog.conf and syslog.conf based
on the the MK_ values rather than change the visible administration
interface that has finger memory, ansible, and puppet support?

>   
>   Both newsyslog.conf and syslog.conf:
>   - /var/log/lpd-errs (MK_LPR != no)
>   - /var/log/ppp.log (MK_PPP != no)
>   - /var/log/xferlog (MK_FTP != no)
>   
>   newsyslog.conf:
>   - /var/log/amd.log (MK_AMD != no)
>   - /var/log/pflog (MK_PF != no)
>   - /var/log/sendmail.st (MK_SENDMAIL != no)
>   
>   MFC after:  3 weeks
>   Sponsored by:   Dell EMC Isilon
> 
> Added:
>   head/etc/newsyslog.conf.d/amd.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/ftp.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/lpr.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/pf.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/ppp.conf   (contents, props changed)
>   head/etc/newsyslog.conf.d/sendmail.conf   (contents, props changed)
>   head/etc/syslog.d/
>   head/etc/syslog.d/Makefile   (contents, props changed)
>   head/etc/syslog.d/ftp.conf   (contents, props changed)
>   head/etc/syslog.d/lpr.conf   (contents, props changed)
>   head/etc/syslog.d/ppp.conf   (contents, props changed)
> Modified:
>   head/etc/Makefile
>   head/etc/newsyslog.conf
>   head/etc/newsyslog.conf.d/Makefile
>   head/etc/syslog.conf
>   head/tools/build/mk/OptionalObsoleteFiles.inc
> 
> Modified: head/etc/Makefile
> ==
> --- head/etc/Makefile Fri May 12 18:37:08 2017(r318249)
> +++ head/etc/Makefile Sat May 13 03:10:50 2017(r318250)
> @@ -8,7 +8,8 @@ FILESGROUPS=  FILES
>  # No need as it is empty and just causes rebuilds since this file does so 
> much.
>  UPDATE_DEPENDFILE=   no
>  SUBDIR=  \
> - newsyslog.conf.d
> + newsyslog.conf.d \
> + syslog.d
>  
>  .if ${MK_SENDMAIL} != "no"
>  SUBDIR+=sendmail
> 
> Modified: head/etc/newsyslog.conf
> ==
> --- head/etc/newsyslog.conf   Fri May 12 18:37:08 2017(r318249)
> +++ head/etc/newsyslog.conf   Sat May 13 03:10:50 2017(r318250)
> @@ -18,7 +18,6 @@
>  #
>  # logfilename  [owner:group]mode count size when  flags 
> [/pid_file] [sig_num]
>  /var/log/all.log 600  7 *@T00  J
> -/var/log/amd.log 644  7 1000 * J
>  /var/log/auth.log600  7 1000 @0101T JC
>  /var/log/console.log 600  5 1000 * J
>  /var/log/cron600  3 1000 * JC
> @@ -26,18 +25,13 @@
>  /var/log/debug.log   600  7 1000 * JC
>  /var/log/init.log644  3 1000 * J
>  /var/log/kerberos.log600  7 1000 * J
> -/var/log/lpd-errs644  7 1000 * JC
>  /var/log/maillog 640  7 *@T00  JC
>  /var/log/messages644  5 1000 @0101T JC
>  /var/log/monthly.log 640  12*$M1D0 JN
> -/var/log/pflog   600  3 1000 * JB
> /var/run/pflogd.pid
> -/var/log/ppp.log root:network640  3 1000 * JC
>  /var/log/devd.log644  3 1000 * JC
>  /var/log/security600  101000 * JC
> -/var/log/sendmail.st 640  10*168   BN
>  /var/log/utx.log 644  3 *@01T05 B
>  /var/log/weekly.log  640  5 *$W6D0 JN
> -/var/log/xferlog 600  7 1000 * JC
>  
>   /etc/newsyslog.conf.d/*
>   /usr/local/etc/newsyslog.conf.d/*
> 
> Modified: head/etc/newsyslog.conf.d/Makefile
> ==
> --- head/etc/newsyslog.conf.d/MakefileFri May 12 18:37:08 2017
> (r318249)
> +++ head/etc/newsyslog.conf.d/MakefileSat May 13 03:10:50 2017
> (r318250)
> @@ -6,8 +6,32 @@ BINDIR=  /etc/newsyslog.conf.d
>  
>  FILES=
>  
> +.if ${MK_AMD} != "no"
> +FILES+=  amd.conf
> +.endif
> +
> +.if ${MK_FTP} != "no"
> +FILES+=  ftp.conf
> +.endif
> +
> +.if ${MK_LPR} != "no"
> +FILES+=  lpr.conf
> +.endif
> +
>  .if ${MK_OFED} != "no"
>  FILES+=  opensm.conf
>  .endif
>  
> +.if ${MK_PF} != "no"
> +FILES+=  pf.conf
> +.endif
> +
> +.if ${MK_PPP} != "no"
> +FILES+=  ppp.conf
> +.endif
> +
> +.if