Hi Stephen,

Thanks for the feedback, it's encouraging to see that some of the items 
could be automated and I appreciate that others will remain manual steps 
for the reasons you've stated.

In the mean time, should we enhance the ReviewBoard documentation so that 
it lists the steps necessary to go from a fresh OS install up to a working 
ReviewBoard site?  The current page lacks some of the steps I've detailed.

https://www.reviewboard.org/docs/manual/2.0/admin/installation/linux/

The current page mixes generic steps with distro specific information, 
which may confuse new users as they try to figure out which steps to apply 
and which to skip.  Despite the risk of duplicating information, I think it 
might be clearer and more concise if we had a separate page for 
RHEL/CentOS/Fedora installation.  Similar pages could be constructed for 
other distros.

If this seems reasonable, then how do we go about updating those pages?  
What format are the pages written in?

The longer term aim is that over time as some of the steps get incorporated 
in the distro packages or within rb-site install, then the manual install 
steps will shrink.

Thanks,
Paul


On Friday, October 31, 2014 12:44:46 AM UTC, Stephen Gallagher wrote:
>
>
>
>
> 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.

Reply via email to