RPM issues.

[Yotam Rubin]

Hello,

Is cross platform portability really an issue here?
How many people use RPM on Solaris or Sco? One would think that properly 
installing RPM on a non-redhat box is more trouble than it's worth.

There's no problem in keeping datafiles in a separate partition whose mountpoint
is /var/log/argus/. 

/usr/local should not be referred to by external sources, whereas external
sources are stuff the user did not create for himself.
It should up to the user to add stuff to the /usr/local hierarchy. 
Note that this in no way prevents backups: Clients are pretty generic
in the sense that few people actually tinker with their code, so simply backing
up the RPM should suffice the wide majority of users. As for user created 
scripts, these should go to the /usr/local/argus hierarchy for the same reasons
that David pointed out in his letter.


	Regards, Yotam Rubin


On Mon, Feb 19, 2001 at 12:23:33PM -0800, David Brumley wrote:
> > Hey Yotam,
> >    So there is no /usr/doc on Solaris, nor /usr/share/doc.
> > So, this is yet another situation where a /usr/argus, or
> > /home/argus, or something would be reasonable?
> 
> 
> 
> I'm going to chime in here.  First, the argument to put argus in
> /usr/sbin and the clients in /usr/bin is not necessarily a bad one.
> With that said, here's some facts and opinions.
> 
> When building an RPM, redhat provides certain default names, like
> {_sbindir} that are basically defines for the place redhat wants you
> to put stuff.  For example, in the RPM I believe I screwed up an
> hardcoded the doc directory, which changed from the 6.x releases to
> 7.1 (maybe others).
> 
> The document I believe is an effort to get people to use those defines
> when building RPM's so that people can find a package once it is
> installed.  Remember, redhat is in some sense catering towards the
> lowest common denominator of lnux users, and while we all know a rpm
> -qipl will list where the files go, newbees will not.
> 
> The reason I think its a good idea to leave it in /usr/argus is the
> same kerberos is in /usr/kerberos.  There are a fair number of clients
> that are specific to argus.  I like this scenario, because I can add
> local processing scripts underneath that heirarchy and back it all up
> together when I rebuild a machine.
> 
> Second, it allows someone to define /usr/argus as their own partition
> to keep data files close together with what collected the files
> (always a good idea with network dump stuff).  In fact, I would change
> the directory to /usr/argus/argus-<major release num> since major release
> numbers are where the data format could potentially change, then make
> a sym link of /usr/argus to the correct version. (Acutally, I would
> *really* move it to /usr/local if I had my way :)
> 
> To address specific points.  I would move the man pages to
> {_mandir}. No problem there.  I would definitely not log to var
> (though this is the default for the startup file...I think we should
> revisit this sometime), because mail and normal size log files
> reside there.  I wouldn't want my /var partition filling up with argus
> data so I couldn't receive mail!
> 
> I would leave the binaries where they are, or adopt a directory
> structure that represents the current release number.
> 
> Carter also makes a good point that there is no good way to address
> the cross platform issues.  (and /opt sucks IMHO!  ever seen the default
> size of the sucker on a solaris install?  it's like 25 megabytes.
> They should do away with that and go to /usr/local like god intended)
> 
> My $0.02 
> 
> -david
> 
> > 
> > > -----Original Message-----
> > > From: owner-argus at lists.andrew.cmu.edu
> > > [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Yotam Rubin
> > > Sent: Sunday, February 18, 2001 8:53 AM
> > > To: argus at lists.andrew.cmu.edu
> > > Subject: RPM issues.
> > > 
> > > 
> > > 
> > > Hello,
> > > 
> > > I wish to address some issues regarding the RPM package of 
> > > argus 2.0.0.beta.5.
> > > 
> > > 
> > >  * It might be wise to split the package into two different packages: 
> > >    argus-server and argus-client. The reason for this is that a user
> > >    may wish to run the argus server on one machine and 
> > > analyze the auditing
> > >    information on another. 
> > >  
> > >  * It's hideously inconsistent with the FHS. Section 4 of the 
> > > FHS clearly
> > >    describes the hierarchy under /usr; Obviously, the argus 
> > > directory is
> > >    not included. 
> > >    
> > >    - Move the binaries to /usr/sbin
> > >    - Move the man pages to /usr/share/man
> > >    - Move the documentation to either /usr/doc/argus or 
> > > /usr/share/doc/argus
> > >    - The output should probably be stored in /var/log/argus. 
> > > There's no need
> > >      to pollute with data/
> > >    
> > > 
> > > Carter, would you like to upload my Debian packages to argus' 
> > > public FTP 
> > > archive? I have prepared packages for the most recent version 
> > > of argus.
> > > 
> > >     Regards, Yotam Rubin
> > > 
> > > 
> > > P.S.: Attached to this letter is the Filesystem Hierarchy 
> > > Standard version
> > >       pre-2.1. 
> > >       
> > >       
> > >   
> > >    
> > >    
> > >    
> > > 
> 
> -- 
> #+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
> David Brumley - Stanford Computer Security -   dbrumley at Stanford.EDU
> Phone: +1-650-723-2445           WWW: http://www.stanford.edu/~dbrumley
> Fax:   +1-650-725-9121  PGP: finger dbrumley-pgp at sunset.Stanford.EDU
> #+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
> Life is a whim of several billion cells to be you for a while.