Guide to the current quagga ON changes
By user12820842 on Apr 03, 2006
proposed ON changes for quagga project
Note: this is a guide to the changes as they are today, and things may of course change - we're still a bit way from code review. The following is a guide to help people navigate the code and get up to speed on what we're trying to do. Referring to the design document will probably be helpful.
The ON changes involve a number of different components:
- changes to routeadm.c to support SMF services
- addition of ipv4(6)-routing(forwarding) SMF services
- addition of value/manage authorizations for routing services
- service conversions for in.routed, in.ripngd, in.rdisc and in.ndpd
changes to routeadm.c to support SMF services
These changes involved:
- extending the functionality of the enable/disable (-e/-d) flags for routeadm to cover SMF services as well as the keywords ipv4-routing, ipv6-routing etc. In the former case, the named SMF service is checked to ensure if it is indeed a routing daemon service (identified by the presence of the "routing" application property group), and if so it is enabled disabled as specified immediately. If ipv4-routing/ipv6-routing etc is specified, the appropriate value is enabled/disabled in routing.conf as before. When "routeadm -u" (update) is run, these state changes are applied.
- adding list/modify functionality for SMF routing services. In the case of "list", we check if the SMF service is a routing service (see above), and if so, list all the "routing" application properties. For modify, the user specifies a list of key=value properties (that must already exist - no routing properties can be created) along with the routing service FMRI.
- adding the list of routing daemon services and their states to the routeadm output. Again, these are identified by presence of a "routing" application property group.
- interacting with ipv4(6)-routing(forwarding) SMF services. When update (routeadm -u) is run, the states of the ipv4(6)-routing(forwarding) services are updated to match those specified in routing.conf. If a service is already enabled, it is restarted (to get updates to daemon arguments for example).
- supporting upgrade. The new SMF commands will not run during upgrade, so instead they append themselves to
/var/svc/profile/upgrade to be run post-upgrade. Upgrade is detected by specification of an alternate root (routeadm -R ) and by the fact that the SMF repository door is not present.
addition of ipv4(6)-routing(forwarding) SMF services
These services need to set ip forwarding flags in the case of ip forwarding services, and for ip routing, they needed to support legacy behaviour. So, for routing services, they check the contents of the ipv4(6)-routing-daemon ipv4(6)-daemon-args and ipv4(6)-daemon-stop-cmd fields in routing.conf. If the contents of these are upgradeable (either to SMF versions of in.routed etc, or to quagga equivalents for zebra daemons), the fields are blanked and the appropriate SMF routing service is enabled. For quagga services, the zebra configuration files are also migrated to /etc/quagga. If the daemon invokations are not upgradeable, for enable, the appropriate daemon is invoked and it's pidfile created. For disable, the stop command is run.forwarding.xml routing.xml
addition of value/manage authorizations for routing services
We create 2 new authorizations in connection with SMF routing services - one covers the changing of routing service states, solaris.smf.modify.routing. All routing-related services should specify this authorization in the "general" property group, to let SMF know it is needed to run the methods for that service. The other new authorization, solaris.smf.manage.routing covers changing of routing service properties (needed for "routeadm -m" to work - see above). We need to augment the network management rights profile to include these new authorizations, as routing management is a part of network management.
Examples of converted services are below.
service conversions for in.routed, in.ripngd, in.rdisc and in.ndpd
All the above are converted to SMF. Each has to have a "routing" property group of type "application" to identify itself as a routing service. Within this, each specifies daemon_args - the arguments to run the daemon with. Since this property is within the routing property group, it is available to "routeadm -m" to modify. We ensure each service method specifies it requires the routing authorization (so the user requires this auth to update state of routing services), and that the routing property group specifies the routing value authorization (so the user requires this auth to change values).