Richard’s approach is very similar to how I’ve been building openafs RPMs recently.
Historically I used RPMs from the CentOS Storage SIG, but they haven’t officially supported OpenAFS and aren’t keeping up to date. Currently I’m trying to leverage Fedora’s COPR system to build and maintain openafs RPMs with the approach Richard (different approach to how Jonathan Billings is using COPR). I was actually working on this the last few days and am getting very close. I’m currently stuck at figuring out how to auto generate a SPEC file to pass COPR along with the generated SRPM. The COPR system appears to want to use a SPEC file to generate the binary RPMs from the SRPM. I haven’t been able to figure out how to generate a functional SPEC file using make against openafs src. -- Bill Glick Sr System Engineer - NCSA - University of Illinois at Urbana-Champaign > On Oct 12, 2018, at 3: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/���(�~���X��X���^�R�w袗�i�(�m��?�X���)zv�����f��f��X��)ߣ�)zv��)
