2011/3/14 Brian Bockelman <[log in to unmask]>:
>> 2011/3/12 Brian Bockelman <[log in to unmask]>:
>>> Took the chance to review Lukasz's new RPMs.  Here are my items of concern:
>>> - We probably want to make sub-RPMs for the different security plugins (ssl, gsi, krb5, etc)
>>
>>   I am not really convinced but don't have strong opinions about this.
> Well, I suppose it depends on how many dependencies all the security plugins pull in.  If it's just OpenSSL and KRB5, then it's probably not too bad.

   I don't think it's much more that OpenSSL on KRB5.

> We should build more of the plugins if possible - I notice we don't currently ship KRB5.

   Hmm, it should have been built in the speck file that I commited.

>>   No, what I try to extract is a long hash of the latest commit on
>> the current branch. It looks like the format option differs between
>> the git versions. I will look into it.
>>
>
> I use the latest SL5 git:
>
> [brian@brian-test http]$ rpm -q git
> git-1.5.5.6-4.el5

   Thanks.

>>> Fixing this, the version number appears something like this:
>>> 20110312.73b5e2f
>>> Could we instead use something like "git describe"'s output?
>>> v3.0.2-90-g73b5e2f
>>
>>   There was a discussion about that at some point. I would prefer to
>> keep it consistent with the stuff that goes into XrdVersion.hh.
>
> My reasoning was that it would help for pre-releases

   I will look into this, but my primary goal is to keep the
versioning scheme consistent between git builds and tarball builds. I
think that I had problem with recreating git describe scheme with
tarball builds.

>>> This is something we can more easily mangle into the RPM.
>>> - makesrpm.sh doesn't work because I have local macros set.  I removed your "dirty hack" and, with the patch below, it works.
>>> - I strongly recommend adding an xrootd user rather than having it run as 'daemon'.
>>
>>   Adding a user account on RPM install is too intrusive and
>> unacceptable for most of our clients.
>
> This is the common practice on the OS platform: MySQL, postgres, apache HTTP, etc.  It's done by the grid middleware packagers and by other CERN IT projects (CVMFS).

   And it's a common source of problems for everyone running cluster
management systems and having a cetralized account management.

> I would strongly suggest this to match the other packagers of xrootd and for security reasons.  I know at least one US lab site that bans running processes under the "daemon" account simply because too many packages use it.

   You can always add the user account by hand and set the account
name you want to use in the /etc/sysconfig/xrootd file.

   Lukasz