OpenOSPFd pkg BETA 0.5.2 produces invalid ospfd.conf
|Priority:||Very Low||Due date:|
|Assignee:||Jim P||% Done:||
|Affected version:||2.1||Affected Architecture:|
Installing OpenOSPFd pkg BETA 0.5.2 on pfSense 2.1-BETA0 (amd64) built on Fri Aug 3 00:17:11 EDT 2012
produces an invalid ospf.conf file, containing the bareword "redistribute" which isn't valid.
Clicking the checkbox at the bottom of the config page next to the empty subnet field changes it to "no redistribute", which also doesn't work.
Apparently the config page doesn't equate a blank field to <missing-data, do not process>.
- Assignee set to Jim P
- Priority changed from Low to Very Low
Not that this doesn't need fixed, but the OpenOSPFd package has pretty much been abandoned in favor of the Quagga OSPF package which is much more well-behaved all around.
#2 Updated by Chris Buechler 10 months ago
We should likely ditch openospfd entirely in 2.1 on. no need for it, Quagga is already a nicer package, doesn't appear to have any of the general openospfd bugs, and having two just confuses people. Definitely warrants a big note in the release notes though since that'll break some people's systems on upgrade.
I thought about making an 'import' feature for Quagga to pull in the config from OpenOSPF since they are so similar. We could also add a tag/feature to the pkg system that could indicate that package A has been replaced by package B, so that during an upgrade or reinstall it will remove A and install B. That would also allow for changing a package's name if needed.
#4 Updated by Adam Thompson 10 months ago
It's unlikely that an import feature would be required - only the most extreme cases would have OSPF configurations so complex they can't be reproduced in five minutes or less. What's more important (IMHO) is updating the package description text to say something like "(deprecated in favour of Quagga OSPFd)" so users have a clue that it's been "pretty much abandoned".
(Which in and of itself is surprising to me, since OpenOSPFd came to exist, in part, because of the low quality of the Quagga implementation!)
Now that 2.1-BETA uses PBI, isn't there a built-in mechanism for stub (or 'transition') packages, i.e. turn OpenOSPFd into an empty package that depends on Quagga? That might not require any changes to the package management front-end...?
#5 Updated by Adam Thompson 10 months ago
Oh, and of course, if the Quagga package does grow an "import" feature, then that's a way to automatically mitigate the breakage-upon-upgrade problem (unless OSPF is required for a default route to the pkg repository, in which case I don't see how you could ever upgrade any OSPFd package without setting static routes temporarily).
#6 Updated by Chris Buechler 10 months ago
we've yet to see a single problem with Quagga's OSPF implementation, and in fact it's fixed scenarios that were having massive problems with openospfd.
An import would be nice, though not strictly necessary, it's easy enough to recreate such configs.
I'd feel more comfortable with an import function, if for no other reason than I can imagine someone trying to do the upgrade remotely while connected to a VPN using OSPF and having it fail to come back up after the reboot. Sure we can put a notice in the release notes and the upgrade guide, but people will still do it, I'm sure. :-)
We can't do any kind of "transition" package the way you describe really, it wouldn't really help anything there. It would just get confusing in the GUI because it would still call itself OpenOSPFD but it would really be Quagga underneath.
I'll see what I can do, at the very least I'll fix the error described here on the ticket and add the note to the package description about its current status.
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset c051bf14000857ffff97ab80273a1a0ea6b62c7b.