Hello,
> > > > Isn't -U pretty close to -Fall ?
> > > >
> > >
> > > it is, however -Fall operates on main ruleset only. -Fall also does
> > > not reset limits and timeouts. Hence my first idea was to introduce
> > > '-FNuke', which kills all rulesets and tables.
> > >
> > > I don't want to change behaviour of existing option ('-Fall'),
> > > therefore
> > > I'm in favor to introduce a new option. Either '-FNuke' or '-U' works
> > > for me. I'm the most concerned about flushing all rulesets.
> > >
> > > Also making "pfctl -a '_1/_2' -Fr" to remove PF 'private' rulesets
> > > works
> > > for me. Actually this is the most important thing I'd like to achieve.
> >
> > whatever gets done here, the initial-raw-state-forcing should be 1
> > operation.
> > not multiple operations acting on aspects of pf.
> >
> > I think if it is multiple operations, people won't ever get comfortable
> > using it.
>
> Not sure about that: I wont be comfortable anyway, as it can cause all sorts
> of problems on a running system.
>
> When i reset things to the boot state, i would expect thats not a simple
> thing and not without issues.
>
> I consider this as a cleanup op, most useful for regress tests, developers
> testing stuff etc. In normal sysadmin work i never needed it.
I think this is a good point. I don't expect experienced admins, who
maintain production systems to use an unconfigure operation. It's indeed
more useful for regression tests and people who are configuring their PF
in sandbox/testing environment.
how about making the '-U' (or whatever name we agree) undocumented. We can
also make the option available if pfctl will get compiled with 'DEBUG'
option (assuming we are doing regress on debug bits anyway).
sashan
