Bug 506100 (opennhrp)
Summary: | Review Request: opennhrp - An NHRP implementation for Linux | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Charles Lopes <tjarls> |
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED DEFERRED | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | david.ward, fedora-package-review, mtasaka, notting, tuju |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://sourceforge.net/projects/opennhrp/ | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-12-13 15:26:15 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Charles Lopes
2009-06-15 15:16:20 UTC
Hi Charles, I cannot sponsor you but I can hopefully provide some useful comments: "libcares.so.2()(64bit)" is picked up as a dependency so "c-ares" is not needed as a Requirement. https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires There are a few rpmlint errors that look to need clearing up: $ rpmlint ../RPMS/x86_64/opennhrp-0.10.3-3.fc11.x86_64.rpm opennhrp.x86_64: W: spurious-executable-perm /usr/share/man/man8/opennhrp.8.gz opennhrp.x86_64: W: spurious-executable-perm /usr/share/man/man8/opennhrp-script.8.gz opennhrp.x86_64: W: spurious-executable-perm /usr/share/man/man5/opennhrp.conf.5.gz opennhrp.x86_64: W: spurious-executable-perm /usr/share/man/man8/opennhrpctl.8.gz opennhrp.x86_64: E: executable-marked-as-config-file /etc/opennhrp/opennhrp.conf opennhrp.x86_64: E: script-without-shebang /etc/opennhrp/opennhrp.conf 1 packages and 0 specfiles checked; 2 errors, 4 warnings. you can details on any particular message with: $ rpmlint -I "executable-marked-as-config-file" Steve Thank you Steve. I have updated the spec file: Spec URL: http://sites.google.com/site/tjarls/fedora/opennhrp.spec SRPM URL: http://sites.google.com/site/tjarls/fedora/opennhrp-0.10.3-4.fc11.src.rpm I used rpmlint on the spec file only and forgot to run it on the rpm. That will teach me about rushing the package cleanup. I corrected the license tag as well. Evening, I'm trying to become a packager myself so apologies if I am learning. During the "make" stage there is one error. It is not obvious that it matters but looks worrying? + make fatal: Not a git repository (or any of the parent directories): .git the build is perfectly successful though. $ rpmlint ../RPMS/x86_64/opennhrp-0.10.3-4.fc11.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. good. Hmm, why are there what look to be scripts as below in etc? /etc/opennhrp/opennhrp-script and /etc/opennhrp/racoon-ph1down.sh Now a more fundamental problem: You have "ipsec-tools >= 0.8" but f11 contains: # repoquery --location ipsec-tools ftp://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/updates/11/x86_64//ipsec-tools-0.7.2-1.fc11.x86_64.rpm i.e it cannot be satisfied without a newer ipsec-tools? Steve Ping. What is the status of this bug? ping again? I have updated the package to version 0.11: http://sites.google.com/site/tjarls/fedora/opennhrp-0.11-1.fc11.src.rpm The git message is harmless. It was used in make to figure out a more precise version of the software. It is gone in this version. The script "/etc/opennhrp/opennhrp-script" defines actions that are triggered by some events like "peer-up". The one that gets installed by the upstream tar ball adds a requirement for racoon to be used conjointly. Racoon in turn has be be configured to call "/etc/opennhrp/racoon-ph1down.sh". I have renamed the script so that it doesn't get picked by default and now force the user to explicitly specify the path for a script to be used. Does anyone have any comments or suggestions on how to better handle this? For using opennhrp in conjunction with encrypted GRE tunnels, either version 0.8 or a patched version of 0.7 of ipsec-tools is required. On the other hand one could technically not use encryption at all although it is strongly encouraged to use it and probably the most common use case. Should we drop the rpm dependency? In addition, a kernel compiled with CONFIG_ARPD is also required (see #502844). I have been thinking about adding a check for that variable in /boot/config-{current-kernel-version} to the rc script. Any comments? Well, - If this package really needs ipsec-tools >= 0.8, please file a RFE bug report against ipsec-tools and mark the bug block this ticket. - Checking CONFIG_ARPD in /boot/config-* of the kernel _currently running_ may be one of the ideas (note that usually people installs several kernels and not always the newest kernel on the system is running) ping? ping again? I will close this bug if no response is received from the reporter within ONE WEEK. Updated versions of the spec and srpm files: http://sites.google.com/site/tjarls/fedora/opennhrp.spec http://sites.google.com/site/tjarls/fedora/opennhrp-0.11-3.fc11.src.rpm Detail of changes: * The startup script checks the /boot/config-`uname -r` for CONFIG_ARPD=y and bails out when not found. * Changed the "Requires" into a "Conflicts" ipsec-tools < 0.8. The use of ipsec-tools >= 0.8 fells under the "Optional Functionality" case. Opennhrp can be run without ipsec-tools although the user would need to write its own script as the two ones shipped upstream use ipsec-tools. Please note that the 0.8 branch of ipsec-tools is not ready for production use. I made some tests with alpha snapshots but I would not recommend using it yet. (In reply to comment #13) > * Changed the "Requires" into a "Conflicts" ipsec-tools < 0.8. The use of > ipsec-tools >= 0.8 fells under the "Optional Functionality" case. Opennhrp can > be run without ipsec-tools although the user would need to write its own script > as the two ones shipped upstream use ipsec-tools. - Well, "Conflicts" means that opennhrp does not work at all if ipsec-tools < 0.8 is installed. Is this really true? Also usually it is required on Fedora that installed packages works as it is by default. As Fedora does not ship ipsec-tools >= 0.8, I would want to request that you write opennhrp-script script which works without ipsec-tools installed or with ipsec-tools < 0.8 installed and configure opennhrp.conf so that opennhrp works on Fedora by default. It is true for all the scripts distributed currently. DMVPN is the main application for NHRP, hence GRE+IPSEC. A safe way would be to place the two script files in their own subpackage, for example opennhrp-ipsec, and have this one conflict with ipsec-tools < 0.8 but that seems a bit overkill. Do you have a particular configuration in mind that would work by default and still be safe? I cannot think of any. (In reply to comment #15) > A safe way would be to place the two > script files in their own subpackage, for example opennhrp-ipsec, and have this > one conflict with ipsec-tools < 0.8 but that seems a bit overkill. ... However from your comment without this opennhrp seems completely useless. > Do you have a particular configuration in mind that would work by default and > still be safe? I cannot think of any. - Please don't think that (potential) reviewers know more things about a submitted package than the submitter of the package. However reviewers expect that the submitted package works on Fedora "as it is" (Of course there are some packages which needs some initialization after being installed, however this package is not in the case). ping? ping again? I will close this bug if no further response from the reporter is received within ONE WEEK. I will revisit once ipsec-tools 0.8 is out then. @Charles Lopes: ipsec-tools 0.8 is in Fedora 15 and later. Are you still interested in this package submission? |