On Thu, 2014-10-30 at 04:33 -0700, Paul Fee wrote:
> Hi Stephen et al.,
>
> I'm trying to get a CentOS7+EPEL install procedure that involves
> minimal setup. My aim is to get most functionality into the distro
> packages so that manual steps are reduced. Thanks for the bugs fixes
> and support so far.
>
> Here's a list of the manuals steps still necessary. I'd like feedback
> if any of these can be automated and incorporated in a package. For
> those that remain manual steps, should we update the install
> documentation to make this easier for others?
>
> Manual steps following CentOS7 minimal install:
>
> 1. Enable EPEL
> $ sudo yum install epel-release
>
EPEL is not part of the standard installation for a reason; it's
community-provided rather than part of the RHEL standard package set.
You can discuss with CentOS whether this should be available by default.
> 2. Install reviewboard, database and memcached
> $ sudo yum install ReviewBoard mariadb-server memcached
>
> 3. Start database server and secure it
> $ sudo systemctl enable mariadb
> $ sudo systemctl start mariadb
> $ sudo mysql_secure_installation
>
These steps we are working on in the Fedora Server product and will
hopefully be part of RHEL 8 (or maybe sometime later in the RHEL 7
lifecycle). Although our first target is postgresql, not MariaDB. Short
version: we intend to have a one-click mechanism to deploy a new DB via
the new rolekit project (Shameless plug: this is my latest effort).
> 4. Create database for use by reviewboard
> $ mysql -u root -p
> > create user review_user@localhost identified by 'review_password';
> > create database reviewboard;
> > GRANT ALL ON reviewboard.* TO review_user;
>
I'll probably try to roll this creation into the rolekit-based
deployment as well.
> 5. Create a reviewboard site
> $ sudo rb-site install /var/www/reviewboard/
>
This part is *very* ReviewBoard specific. We can't hard-code a path into
the packages and we can't automatically deploy because we don't know the
database information without user input (and RPM installs are
non-interactive, unlike Debian packages with debconf. That's a whole
other topic though).
> 6. Adjust httpd configuration
> $ sudo ln
> -s /var/www/reviewboard.bfs.tsp/conf/apache-wsgi.conf /etc/httpd/conf.d/
>
This is something we could work into the package; we could potentially
carry a distribution-specific patch that automatically creates this
symlink during 'rb-site install'. Ideally, I'd like to do this as a
build flag upstream, so that other distributions could do so as well,
but a first path could be a Fedora/EPEL-specific patch.
> 7. Start web server
> $ sudo systemctl enable memcached
> $ sudo systemctl start memcached
> $ sudo systemctl enable httpd
> $ sudo systemctl start httpd
>
Fedora has a strict policy against *automatically* enabling services to
start at boot without user intervention. We *could* add a flag for
'rb-site install' that would say "start automatically after completion",
but not until we've already handled item 6 above.
We won't be able to do so for memcached, however. Since it isn't
guaranteed to be running on the same system... However this does raise
the point that I should probably add memcached to the systemd unit file
so that if it IS being run on the same system, it's started in the right
order. Though this is a low risk of a race, since memcached isn't
accessed by ReviewBoard at start-up time to the best of my knowledge;
only on requests. So probably both will be available before clients are
allowed to talk to the system.
I'll patch that in the package but I'm not going to spin another build
just for that, I think. (Sorry for the ramble; thinking as I type).
> 8. Adjust site file permissions
> $ sudo chown -R
> apache /var/www/reviewboard/data /var/www/reviewboard/htdocs/media/ext
> /var/www/reviewboard/htdocs/static/ext
> /var/www/reviewboard/htdocs/media/uploaded
>
Again, we can probably solve this with a patch that can accept a
distribution-specific build-time value. The real issue here is that the
user name for the apache server differs between OSes, so we can't just
assume it's 'apache' and make the change automatically upstream in the
eggs. However, in distribution packaging, this value is guaranteed to be
known, so we can add it there.
Again, I'd prefer this to be turned into an upstream patch with an
optional build-time configuration so that other distributions can
benefit.
> 9. Adjust site SELinux permissions
> $ sudo setsebool -P httpd_can_network_memcache 1
> $ sudo chcon --type=httpd_sys_rw_content_t /var/www/reviewboard/data
> $ sudo chcon
> --type=httpd_sys_rw_content_t /var/www/reviewboard/htdocs/media/ext
> $ sudo chcon
> --type=httpd_sys_rw_content_t /var/www/reviewboard/htdocs/static/ext
>
This is something I've meant to do in the Fedora packages for a long
time. Again, this will require changes in 'rb-site install' because we
don't know where the site path will be in advance. Thank you for the
specific steps above, by the way. I've been meaning to figure those out
for quite some time, but it never floated to the top of the priority
queue.
Again, in an ideal world I'd build this as a conditional build-time
feature in upstream, since I don't like carrying downstream patches if I
can help it. However, since it'll likely only benefit Fedora and EPEL, I
may carry this one myself. This is not dependent upon the other ones
above.
> 10. Open port 80 on firewall
> $ sudo firewall-cmd --add-port=80/tcp
> $ sudo firewall-cmd --permanent --add-port=80/tcp
>
Classically, we don't open firewall rules automatically because it's
impossible to know with certainty which interfaces it should be allowed
on. If you have a multi-homed server, you may only want it on one or the
other of the interfaces (such as available on the private network and
not on the public one).
We could probably add a (non-default) convenience option to 'rb-site
install' similar to item 7 above that allows us to just say "Open the
port on all interfaces". I say non-default because accidental service
leakage is a Bad Thing, especially with Django's security history.
> My understanding of packaging guidelines is that Fedora/RHEL packages
> shouldn't start services automatically, so perhaps these steps will
> always be necessary. Also the site directory does not below to the
> ReviewBoard package, so only "rb-site" would be able to fix the
> permission issues (steps 8 and 9).
>
> Have I missed anything in this list? Can any of these steps be
> incorporated in the ReviewBoard package or within the rb-site command?
> Perhaps rb-site could include hooks for distros to plug into their own
> customisations, e.g. SELinux configuration on Fedora/RHEL.
I think there's certainly room for improvement. My schedule these days
is pretty full, so I haven't been focusing much on enhancements (as with
last week, it can be hard even to keep up with the releases), but we
should probably open some of these as RFEs so they can be tracked. Some
of them are probably pretty easy (with a little mentoring), so perhaps
they could become part of an intern project or GSoC effort.
--
Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
---
Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
---
Happy user? Let us know at http://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
