Break sorting out into a common file so formats and modes use the same
code. Also add -O for sorting to the list commands. From Dane Jensen in
GitHub issue 4813.
productivity/baikal: add timezone workaround for recurrence expansion
As explained in [0], when creating a calendar via the web interface, Baikal
sets cal:calendar-timezone to a timezone string instead of a VTIMEZONE object.
This causes an issue when querying events with expanded recurrences, see [1].
To work around this, create a new DateTimeZone object from the string.
[0] https://github.com/sabre-io/Baikal/issues/1241
[1] https://github.com/sabre-io/Baikal/issues/1325
improve pf_find_state lookups by checking the direction of the states.
if we have the state from the packet coming into the stack we can
ensure the state we look up goes in the opposite direction.
use pf_states to link mbufs/inpcbs and forwarded connections together
this replaces the links between pf_state_keys and mbufs/inpcbs.
pf_states represent the actual connection tracked by pf, while
pf_state_keys are more general since they only contain the network
addresses. the fact that pf_state_keys exist is an implementation
detail in pf rather than a fundamentally useful artifact to the
rest of the system. the preference would have been to link things
to pf_states rather than pf_state_keys in the first place, but there
wasn't enough machinery (eg, refcounts and immutable links to
pf_state_keys) on pf_states to link to them directly. this means
pf still had to iterate over the states hanging off the pf_state_keys
to get to the actual pf_state it needed anyway.
discussed with henning@
ok sashan@ jmatthew@
have state and source limiter state cleanup assert on the right lock.
state and source limiters and they pf state links they're wired up
with are protected by the pf lock, not the pf state lock. this is
asserted correctly when setting up source and state limiters, but
i copy and pasted the wrong assert for the cleanup code.
this should fix the spurious "splassert: pf_create_state: want 1 have 0"
messages i get on my firewalls.
import OpenVoxDB
OpenVoxDB is a fork of Open Source PuppetDB.
OpenVoxDB is the fast, scalable, and reliable data warehouse for OpenVox.
It caches data generated by OpenVox, and gives you advanced features at
awesome speed with a powerful API.
lots of valuable feedback and final OK kn@
import ruby-openvoxserver-ca
This gem provides the functionality behind the OpenVox Server CA
interactions. The actual CLI executable lives within the OpenVox Server
project.
feedback and OK kn@