As far as I know, I don't believe support for RPMs has been dropped. From my understanding, it's just a matter of who does the release and if they have access to RPM-based systems to make the source RPM (SRPM) for said release (but I could be wrong).
If the SRPM doesn't get put out with the release, we essentially follow the instructions Richard sent, with a couple minor differences. The latest instructions from OpenAFS for how to create RPMs is here: https://wiki.openafs.org/devel/HowToBuildOpenAfsRpmPackages/ (very similar to Richard's). We use those instructions to create a SRPM (created by the 'make srpm' line) and then create our RPM packages from that SRPM (we have a process already for building RPMs from a SRPM, but the rpmbuild command on the link above works too). This almost always works well for us on RHEL 6 and RHEL 7 systems (and usually Fedora systems too). Hope this helps! Thanks. -- Matt Vander Werf HPC System Administrator University of Notre Dame Center for Research Computing - Union Station 506 W. South Street South Bend, IN 46601 On Fri, Oct 12, 2018 at 4:26 PM Richard Brittain < [email protected]> wrote: > On Fri, 12 Oct 2018, Sebby, Brian A. wrote: > > > Previous releases have included source RPMs that made it easier for us > to build RPMs to deploy to our Red Hat-based servers. > > I was hoping it maybe had just not yet been released yet, but there > still isn’t a source RPM for 1.6.23. It looks like one > > was built for 1.6.24.4, so I may just end up deploying that since we do > not use any of the backup utilities. I know that > > support for RPMs from OpenAFS is something that’s been discussed for a > long time, but I hadn’t seen any official announcement > > (unless I missed it) that indicated that they would no longer be created. > > > > For any other folks using Red Hat – what are you doing for deploying > OpenAFS? Are there any repos out there equivalent to > > the Ubuntu PPA? > > I've never managed to go from source tarball to clean RPMs. I found a wiki > entry explaining how make a srpm, but it didn't work for me, at least for > recent releases. > > However, there is a wiki entry explaining how to build from a git > checkout, and that worked once I had all the GNU autotools in place. I'm > sure this procedure does far more work than needed, but this is the brief > summary of steps: > > $ cd ~/projects/openafs/1.8.2 > $ git clone git://git.openafs.org/openafs.git > $ cd openafs > $ git checkout openafs-stable-1_8_2 > $ ./regen.sh > $ ./configure --enable-transarc-paths --enable-checking > --enable-supergroups > $ make dist > $ make srpm > $ rpmbuild --rebuild -ba --define "_topdir `pwd`/rpmbuild" --with kauth > packages/openafs-1.8.2-1.src.rpm > $ cd rpmbuild/x86_64/ > > - copy the resulting RPMs to local distribution point. > > This worked cleanly on RHEL6 and RHEL7 > > Richard > > > Brian > > > > > > > > -- > > > > Brian Sebby ([email protected]) | Information Technology Infrastructure > > > > Phone: +1 630.252.9935 | Business Information Services > > > > Cell: +1 630.921.4305 | Argonne National Laboratory > > > > > > > > > > > > From: <[email protected]> on behalf of Benjamin Kaduk < > [email protected]> > > Date: Tuesday, September 11, 2018 at 2:09 PM > > To: <[email protected]> > > Cc: <[email protected]>, <[email protected]> > > Subject: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available > > > > > > > > > > > > The OpenAFS Guardians are happy to announce the availability of > > > > Security Releases OpenAFS 1.8.2 and 1.6.23. > > > > Source files can be accessed via the web at: > > > > > > > > https://www.openafs.org/release/openafs-1.8.2.html > > > > https://www.openafs.org/release/openafs-1.6.23.html > > > > > > > > or via AFS at: > > > > > > > > UNIX: /afs/grand.central.org/software/openafs/1.8.2/ > > > > UNC: \\afs\grand.central.org\software\openafs\1.8.2\ > > > > UNIX: /afs/grand.central.org/software/openafs/1.6.23/ > > > > UNC: \\afs\grand.central.org\software\openafs\1.6.23\ > > > > > > > > These releases include fixes for three security advisories, > > > > OPENAFS-SA-2018-001, OPENAFS-SA-2018-002, and OPENAFS-SA-2018-003. > > > > > > > > OPENAFS-SA-2018-001 only affects deployments that run the 'butc' utility > > > > as part of the in-tree backup system, but is of high severity for > > > > those sites which are affected -- an anonymous attacker could replace > > > > entire volumes with attacker-controlled contents. > > > > > > > > OPENAFS-SA-2018-002 is for information leakage over the network via > > > > uninitialized RPC output variables. A number of RPCs are affected, > > > > some of which require the caller to be authenticated, but in some cases > > > > hundreds of bytes of data can be leaked per call. Of note is that > > > > cache managers are also subject to (kernel) memory leakage via > > > > AFSCB_ RPCs. > > > > > > > > OPENAFS-SA-2018-003 is a denial of service whereby anonymous attackers > > > > can cause server processes to consume large quantities of memory for > > > > a sustained period of time. > > > > > > > > Please see the release notes and security advisories for additional > details. > > > > > > > > The changes to fix OPENAFS-SA-2018-001 require behavior change in both > > > > butc(8) and backup(8) to use authenticated connections; old and new > > > > versions of these utilities will not interoperate absent specific > > > > configuration of the new tool to use the old (insecure) behavior. > > > > These changes also are expected to cause backup(8)'s interactive mode > > > > to be limited to only butc connections requiring (or not requiring) > > > > authentication within a given interactive session, based on the initial > > > > arguments selected. > > > > > > > > Bug reports should be filed to [email protected]. > > > > > > > > Benjamin Kaduk > > > > for the OpenAFS Guardians > > > > > > > > > > > > ----- > Richard Brittain, Research ITC > Information, Technology and Consulting, > 37 Dewey Field Road, HB6219 > Dartmouth College, Hanover NH 03755 > [email protected] 603-646-2085 > http://rc.dartmouth.edu/
