[Bug 851279] New: Review Request: eucalyptus - Elastic Utility Computing Architecture

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=851279

            Bug ID: 851279
        QA Contact: extras-qa@xxxxxxxxxxxxxxxxx
          Severity: unspecified
           Version: rawhide
          Priority: unspecified
                CC: notting@xxxxxxxxxx,
                    package-review@xxxxxxxxxxxxxxxxxxxxxxx
          Assignee: nobody@xxxxxxxxxxxxxxxxx
           Summary: Review Request: eucalyptus - Elastic Utility Computing
                    Architecture
        Regression: ---
      Story Points: ---
    Classification: Fedora
                OS: Unspecified
          Reporter: agrimm@xxxxxxxxx
              Type: Bug
     Documentation: ---
          Hardware: Unspecified
        Mount Type: ---
            Status: NEW
         Component: Package Review
           Product: Fedora

Name        : eucalyptus
Version     : 3.1.0
License     : GPLv3
URL         : http://www.eucalyptus.com
Summary     : Elastic Utility Computing Architecture
Description :
Eucalyptus is a service overlay that implements elastic computing
using existing resources. The goal of Eucalyptus is to allow sites
with existing clusters and server infrastructure to co-host an elastic
computing service that is interface-compatible with Amazon AWS.

SPEC:
http://arg.fedorapeople.org/reviews/eucalyptus/3.1.0-16/eucalyptus.spec

SRPM:
http://arg.fedorapeople.org/reviews/eucalyptus/3.1.0-16/eucalyptus-3.1.0-16.fc18.src.rpm


There are a number of lint warnings.  I'll go through my rationale on them:

1) eucalyptus.x86_64: W: dangerous-command-in-%pre tar

This could be changed to copy commands if that's deemed "safer" ... this is how
upstream packages currently work, though.

2) dangling-symlink (many of these)

Eucalyptus relies on all jars being in a common directory.  jetty does
something similar in /usr/share/jetty/lib.  All symlink targets are unversioned
jar filenames and are contained in Requires. 

3) explicit-lib-dependency (json-lib and cglib)

Bogus.  These are java packages

4) install-file-in-docs

The install file does also contain some setup instructions, but I could get rid
of it.

5) log-files-without-logrotate

We use log4j to rotate almost all of our logs.  We may instate logrotate for
the remaining logs

6) no-documentation

Subpackages depend on the eucalyptus package, which contains docs.  The only
exception is the python admin tools, which are actually licensed separately (as
BSD) but do not ship a license file at this time.

7) no-manual-page-for-binary

Eucalyptus does not create manual pages for most binaries.  End-user binaries
have help text, and I've used help2man for some of those.  The service binaries
are not really intended to be run by an end user in most cases, and could
perhaps be moved into libexec

8) non-conffile-in-etc

We may simply need to relocate /etc/eucalyptus/cloud.d entirely.  I'm just not
certain of the right place, and would like advice on this.  In some cases,
these are files that users may want/need to modify (jrxml templates for
jasperreports, for example).  Generally they won't be modified, though.

The file not in /etc/eucalyptus should likely be config files.  I'll talk to
our developers about this.

9) non-standard-dir-perm 0700

I'm not sure why 0700 is strange.  The instances of this are mainly sensitive
data which should only be readable by the eucalyptus user.

10) non-standard-executable-perm / setuid-binary (these are related)

The "rootwrap" and "mountwrap" binaries, unfortunately, are used to give
eucalyptus root privileges for specific operations.  I wish this were better,
but this is how eucalyptus currently works

11) non-standard-gid / non-standard-uid

eucalyptus owns a number of directories, usually so that permissions can be set
to 0700

12) only-non-binary-in-usr-lib

This is RHBZ 794777

13) spelling-error

This is due to our acronyms (NC, CC, SC)

Sorry, that's a lot to work through.  Hopefully some brave reviewer can take
this on.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review



[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]