X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8861E.EFC0B4A2@onstor-exch02.onstor.net>; Fri, 14 Mar 2008 15:01:20 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Review Request :  TED00021741 and TED00022673
Date: Fri, 14 Mar 2008 15:01:20 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E056C9499@onstor-exch02.onstor.net>
In-Reply-To: <20080314142337.39386478@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Review Request :  TED00021741 and TED00022673
Thread-Index: AciGGasYhCYG1oW/Q6i0anUgqTcOdgAAdDpQ
From: "Larry Scheer" <larry.scheer@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>,
	"Kumar Vakacharla (HCL)" <kumarv@onstor.com>

See Larry> inline below for my comments (exim4-base and at the very end
of this thread)

-----Original Message-----
From: Andy Sharp=20
Sent: Friday, March 14, 2008 2:24 PM
To: Kumar Vakacharla (HCL)
Cc: Larry Scheer
Subject: Re: Review Request : TED00021741 and TED00022673

On Fri, 14 Mar 2008 11:50:05 -0700 "Kumar Vakacharla (HCL)"
<kumarv@onstor.com> wrote:

> Andy,=20
>=20
> =20
>=20
>       Please find my responses inline.=20
>=20
> =20
>=20
> linux/rootfs/Makefile
>=20
> =20
>=20
>      logrotate exim4 probably should be done as part of the exim4
>=20
>      package.
>=20
> =20
>=20
> linux/rootfs/etc/logrotate.d/exim4-base
>=20
> =20
>=20
>      >>add linux/rootfs/etc/logrotate.d/exim4-base
>=20
> =20
>=20
>      nope.  make the change to the package.  i'm happy to do it for
> you,
>=20
>      or you can learn some stuff by doing it yourself ~:^)  doesn't
>=20
>      need to be part of this checkin.
>=20
> =20
>=20
>      BTW, exim-cleaning.log is handled in /etc/logrotate.d/onstor
>=20
> =20
>=20
> =20
>=20
> Kumar> I believe by adding this file I am overwriting the package
> Kumar> file.
> Change to the package is fine but then we need to change every time we
> get a new version of that package. Am I right??

Well, yes, and no.  We are building this package ourselves, with our
modifications, so we shouldn't also then overwrite it.  Only one or the
other ~:^)

> Path of exim-cleaning.log defined in /etc/logrotate.d/onstor is
> different from the one specified in logrotate.d/exim4-base. I don't
> know whether both are really different files.=20

There should be nothing in exim4-base logrotate about this log file.  I
see on my cougar that there is.  I suspect Larry is not building the
base root filesystem with an up-to-date version of the package.

Larry> What is installing in the rootfs is :
       exim4-base 1:4.63-17
 	//depot/dev/linux/Pkgs/binary/Deb/exim4-base_4.63-17_mipsel.deb
      ... #3 change 27953 edit on 2008/02/20 by andys@ripper (binary)
      'Add a cron.daily file to limit '
Larry> If that is not the up-to-date version of the package then what
is?
Larry> Where is it? And why is it not in the perforce depot?

> I may need your help If I have to really change the file in exim4
> package as I have no idea about where to get that file in the package.

I'm quite happy to provide assistance or answer any questions you might
have.  I did the exim4 package stuff, so I know it pretty well.  I did
it in the way we are supposed to modify standard packages from now on,
which is to add patches which are applied at the time the package is
built.  That way, we can get an updated version of the package and
expect to be able to just drop it in and have it work, unless one of
the patches fails to apply, which I expect will be a low occurance.
The idea is to make it feasible to keep our userspace up to date
including our customizations.  The way we did things previously, it
really wasn't feasible to keep the software updated, which resulted
in a mess, which is bad.

The exim4 package is in linux/Pkgs/source/exim4.  You have to build it
on a filer with the right build dependencies installed.  I just so
happen to have a Bobcat with all of them installed ~:^)  You can log in
and build the package there.  It's g7r9.  Before you build the packages,
you need to check out with perforce for editing the packages, which are
in linux/Pkgs/binary/Deb/exim*.deb (there are three).  Make your change
to the patch in linux/Pkgs/source/exim4 (that file is already being
patched, so you can just add your modification to that patch).  Then,
on g7r9, logged in as yourself, you can just type "make" in that
directory, it will build the packages, and copy the appropriate ones
into linux/Pkgs/binary/Deb/ and then you just a review away from
checking in the change.
=20
> linux/rootfs/etc/cron.daily/sysklogd
>=20
> =20
>=20
>      changes not needed to this file.  also remove it from makefile.
>=20
> =20
>=20
> =20
>=20
> Kumar> The script /usr/sbin/syslogd-listfiles will be executed by
> cron.daily every day. =20
>=20
> So, this script will list the /var/log/onstor/messages file in its
> output if the file size exceeds 1MB and=20
>=20
> savelog compresses it thereafter which is not we want.=20

Hmm, OK, that rule wasn't exactly spelled out in the man page.  Leave
as is then.


> linux/rootfs/etc/cron.weekly/sysklogd
>=20
> =20
>=20
>      >>add linux/rootfs/etc/cron.weekly/sysklogd
>=20
> =20
>=20
>      line 26, trailing whitespace
>=20
> =20
>=20
> Kumar> Done.=20
>=20
> =20
>=20
> =20
>=20
> linux/rootfs/etc/logrotate.d/onstor
>=20
> =20
>=20
>      line 4 please leave the 'weekly' in there.  i want it to rotate
>=20
>      on size before it does it "just because".  if we find this has
>=20
>      to be changed, we can adjust it later.  let me know if you think
>=20
>      differently.
>=20
> =20
>=20
> Kumar> As I said in earlier mail, this "weekly" directive is
> Kumar> overwriting
> the size directive which is mentioned before it hence=20
>=20
> it rotates the file only once per a week. I think this is the property
> of logrotate.

As I understand it, the size directive says rotate if larger than this
size, and the weekly says rotate once a week regardless of size.  Both
rules are in affect at the same time.  So the file will be rotated at
least once a week, and more often if it grows beyond the size limit.  My
feeling is that currently on BSD we try to cover up a lot of
bugs/badness by rotating the log file every hour or some nonsense. This
hourly log rotation consumes a lot of resources unnecessarily on most
systems.  I don't want the log file rotated more often than weekly if
it isn't larger than 60KB, and possibly that number should be as much
as 10x that.  But currently on BSD it's 40KB, so I didn't want to freak
people out too much. And in the meantime we need to do some work to cut
down on the log spammage that is all over the place, especially in the
FP and TXRX code.

> linux/rootfs/etc/syslog.conf
>=20
>      >>add linux/rootfs/etc/syslog.conf
>=20
>      an excellent start.
>=20
>      since we're here, remove the following entries:
>=20
>      uucp.*
>=20
>      news.*
>=20
>      the xconsole entry (at the end)
>=20
> =20
>=20
> Kumar> Done.=20
>=20
> =20
>=20
> =20
>=20
> nfx-tree/code/ssc-elog/syslog.conf.linux
>=20
> =20
>=20
>      i'm confused.  what is this file v. the previous file in the
>=20
>      changelist?  we don't need both.  if you have added a syslog.conf
>=20
>      to rootfs, you shouldn't need this one, too?  what am i missing?
>=20
> =20
>=20
> =20
>=20
> Kumar> This is the file which goes to build as /onstor/etc/syslog.conf
> and will be used as template file.=20

Aha.

> The earlier file (/rootfs/etc/syslog.conf) goes to build
> /etc/syslog.conf. =20
>=20
> Every time when we change elog configuration it will overwrite the
> contents of /etc/syslog.conf with=20
>=20
> the template file in /onstor/etc and thereafter it appends our
> customized changes to the new /etc/syslog.conf file.
>=20
> (pls see function elog_updateSyslogConf)

Same file should be used for both.  Having two separate files is a bug
waiting to happen.  My preference is to eliminate the one in nfx-tree,
where it's buried, and just use the one in rootfs.  At "make release"
time just have it copied to both places.  I'm cc'ing Larry on this to
have him weigh in with an opinion.

Larry> Due to the way the legacy systems work we may be unable to remove
the file from the nfx-tree. The easiest path for both cougar and the
legacy platform is leaving the file in the nfx-tree and let me overwrite
the system version of this file with the nfx-tree version using the
linux/rootfs/Makefile. Don't add the file to linux/rootfs/etc just add
the make target and rule. We do this with the services file.
