requests do not apply

[philippenc]

Hello,

I probably have a misunderstanding of the documentation, but the POST requests I send are not being applied on pfSense. However, I am getting a "200" status code in response. To keep it simple, I tested the request /api/v2/diagnostics/halt_system from https://mypfsense/api/v2/documentation#/ and it didn't work, which is normal because the API REST details state "Applies immediately: No". I also tested from a Python script:

def post_system_halt():
    api_url = 'https://192.168.0.155/api/v2/diagnostics/halt_system'
    headers = {
        'accept': 'application/json',
        'Authorization': f'Bearer {token}',
        'Content-Type': 'application/json'
    }
    data = {"dry_run": True}
    response = requests.post(api_url, headers=headers, json=data, verify=False)
    print('response.status_code', response.status_code)
    print('response.json', response.json())

The response code is "200" but pfSense does not shut down.

How can I apply the request?

Thank you.

[jaredhendrickson13]

This topic can get pretty complex but to answer simply, the 'Applies immediately' attribute in the documentation is primarily intended for endpoints that interact with the pfSense configuration. It specifies whether the pfSense configuration is only written to the configuration and must be applied later by calling a separate 'apply' endpoint, or if it is applied on the backend as soon as it's written to configuration. This is intended to allow the same behavior as the 'Apply changes' button in the webConfigurator.

For example, with firewall rules, you can continue to create more rules and but the rules will not be applied on the backend until that 'Apply changes' button in the UI is clicked. The same behavior exists in the REST API. You can create and/or modify as many firewall rules as you'd like but the changes do not apply immediately until you call the /api/v2/firewall/apply endpoint. There is also the apply control parameter which changes the behavior to always apply the change automatically by setting apply to true in your request.

This behavior is briefly mentioned in the apply control parameter description, but there is probably some documentation adjustments that need to be made to make this behavior more clear. I can work on some enhanced documentation around this.

---

As for the API call you're making, the 'Applies immediately' attribute isn't really applicable because it does not write anything to the configuration. However, the shutdown is not being performed in your case because the dry_run field is set to True. This will run through the API call as usual but doesn't actually initiate the shutdown. Setting that field to False should initiate the shutdown. That field is really only there for testing purposes where you want to make sure the call runs all the way through but don't actually want to shutdown the system.

[philippenc]

"Thank you for all these responses. However, in the case of modifying the DHCP, I don't see an API /api/v2/services/dhcp_server/apply to apply the addition of an entry via /api/v2/services/dhcp_server/static_mapping. In the details, it is written 'Applies immediately: Yes', but my addition is not being applied. The response code is '200'. I tested it on a DHCP interface where no static mapping entries existed, so it was not impacted by commit 5ef2b94."

[jaredhendrickson13]

Just to confirm, it's not being applied on the backend service (dhcpd/kea) or it's not being written to the pfSense configuration at all?

[philippenc]

it is not written in the configuration file at all

[jaredhendrickson13]

That would likely be unrelated to applying the changes then since the config write occurs before that step. However, this has been seen before and it's typically for one of these three reasons:

1. You can have the 'Config Deny Write' privilege assigned to your authenticating user. This will allow the API call to run all the way through, but pfSense transparently denies the configuration write on the backend. There will often be a system log entry associated with this event.
2. There has been a bad configuration write and pfSense has automatically rolled back to the last 'good' config. Check for a file at /conf/config.xml.bad on your pfSense instance.
3. There is an issue with the pfSense installation itself or the PHP environment. This can sometimes happen when the configuration cache gets polluted or when certain PHP processes get stuck. There are a few things you can try to fix it:
   • Run /etc/rc.php-fpm_restart to restart PHP services
   • If possible, reboot pfSense and see if the problem still occurs afterwards.
   • Spin up a new test instance of pfSense, install the REST API and retry the API call. If it works, there is likely an issue with the underlying pfSense installation.

[philippenc]

Hello and thank you. Only the reinstallation of pfSense, configuring my interfaces, and then installing the REST API resolved the problem. Thank you for your efforts.

Philippe