Testing some development - how to install xdebug for 2.4.5-p1?

stilez

I'm hacking round with 2.4.5-p1 in a VM, so I don't mind if I break most things (snapshots etc solve it all!)

I've got external repos working, so I can access most FreeBSD dev tools I need. But what I really want is xdebug right now, to figure out a tricky issue in a possible PR - and pkg search xdebug only shows "php73/php74/php80-pecl-xdebug-3.0.2", whereas 21.4.5-p1 is based on php72.

I see that xdebug 3.0.2 is apparently compatible with php72 anyway anyway. So should I:

install php73-pecl-xdebug-3.0.2 and then fix the config to work with php72
or
download xdebug packaged for php72 instead

If the first, what config is needed, if the second what download link can I find xdebug *.txz for php72 on AMD64 FreeBSD 11.x, suitable for pkg, at?

I'm familiar with php but not so much with the FreeBSD core OS itself, so if I've missed a trick, please let me know.

Gertjan

@stilez

That 'VM' part, that was the good start.
Create another one. Boot it up with a normal OS, like a recent Debian. Install apache2 or nginx, add your PHP version, and go haywire with that.
Better : for a $/€ a month you have your own domain name, add another $/€ and you have your own VPS, and make a real 'web site'.

pfSense, true, uses PHP as the language that generates html pages that are needed to drive the GUI that is used to create the settings that are necessary to create the config for each program and service that takes care of what pfSense does : routing and fire-walling.

pfSense does not use the classic FreeBSD file system layout. So install non-pfSense FreeBSD packages would give a messy result at best. Break the system at most. The fact that 'pkg' allows you to install from the public freeBSD package repositories doesn't mean it's useful.

The PHP part of pfSense is not - at all - the a good part of learning PHP.
Btw : BASIC is 'dead'. PHP is nice, but old, somewhat messy. Knowing how to read it us very useful. Like having a driving license, see it as a more modern general education thing.

Mixing PHP a.b and PHP a.c extensions is a real bad idea. Only experts do so..... and guess what : they don't. Do what I prosed above : VM => OS => Web server => install PHP a.b and an extension a.c (if it allows you to do so). You wind up with a functional PHP a.b set-up, and a minimal PHP a.c setup and with some file extension fiddling or 'per virtual web server' setting you can choose what PHP version you want to use for what page or what 'web site'.

I advise you to use pfSense to learn the things it does. The GUI part is really not that interesting.

Btw : you already have the best PHP debugger : your browser.

And don't be surprised that, when you finally master the PHP part of pfSense, the authors ditch it completely to go for Python ....

stilez

@gertjan

Starting at the end, going for python wouldn't surprise me. It's been in the pipeline for maybe 5 years or more.

I think you're confusing me with someone who wants to learn web dev generally. I've no use or interest in a domain, no interest in general setups, never used nginx or apache outside a prepackaged build nor any general purpose *nix other than some basic FreeBSD experience, and browser debugging is good for javascript/html but not so useful for the back-end pfSense PHP code. But seeing as pfSense back end is coded largely in PHP with OS service calls, I don't need most of that -- although I agree it would be nice to know, thats several years learning to achieve.

Instead, all I care about is the back end, where $config[...][...] is being manipulated (or not assigned correctly) and Im missing it. I want the quickest direct route to getting a standard 2.4.5-p1 install working with xdebug to figure where the heck something in the back-end that I'm not seeing, takes place. The rest is working fine, and debugging via text editor and CLI for the most part is sufficient. But Im hitting a wall on this, mass use of var_dump isn't helping, and being able to track PHP's assignment/changes to variables, and where they take place, will help. That's literally all I need.

I know thats not the way a skilled dev or purist would do it, and probably horrifies ("Why not learn to do it properly" - I will but time's not on my side), but it's served me enough to write code to a high standard, find security lapses/validation/sanitisation issues, and other bugs/vulnerabilities in the pfSense base code before, and have a fair number of PR's accepted, and it's good enough for now. All I'm missing is variable assignment tracking, to find what's modifying $config when I can't spot it. I don't much care if it all falls over, once I get a trace of that variable assignment enough to find where it's modified.

Any hints of the cheapest quickest and if needed dirtiest way to achieve that on a standard 2.4.5-p1 build, gratefully appreciated! :)

Gertjan

@stilez said in Testing some development - how to install xdebug for 2.4.5-p1?:

Instead, all I care about is the back end, where $config[...][...] is being manipulated (or not assigned correctly) and Im missing it

I'll bookmark your post for this weekend, and give you some pointers. The reading and writing is done in one file, and it lives in /etc/inc/.

(or not assigned correctly)

That would break the functionality of the related part of the GUI.
Input checking is done every where and of course never done enough ^^
better be safe then sorry : if you(re not using an us style language, keep everything to pure ASCI chars, and nothing else. Even descriptions. I know all about it, using the fr_FR .

@stilez said in Testing some development - how to install xdebug for 2.4.5-p1?:

mass use of var_dump isn't helping, and being able to track PHP's assignment/changes to variables, and where they take place, will help. That's literally all I need.
I know thats not the way a skilled dev or purist would do it, and probably horrifie ....

Noop, that close to what I'm doing, actually.

edit : What I'm doing often : copying the closest syslog() like function, or whatever logs in the neighbourhood of the code I like to check, and place these on strategic places. It's rare I output to the screen : I'm a read-the-log-man.

stilez

@gertjan

Thanks. This is a rough description what I'm trying to do.

The issue I have is, I'm working on code that is very similar to firewall_rules_edit. I've used that page, modified the form and validation (only) and it looks fine. When the form POSTs, it sets some stuff in $config. I can see it set. But it isn't there when I check.

I've tweaked firewall_rules_edit.php with the identical code and get the identical issue. So I'm using that to trace whats happening. If I modify firewall_rules_edit.php (for example) and comment out the redirect/exit to firewall_rules.php after a successful form save, and instead have it continue back to the form and echo "\n\n" just below $input_errors (if any), I see that the HTML contains the full $config and it contains my modified data. However when firewall_rules.php reloads, or I dump $config using command prompt, I get the full $config - but my updated values aren't in it.

I've looked for all kinds of possible reasons. $config is loaded as a global in firewall_rules_edit.php and my values are saved using the same code pathway as updated firewall rules. $config contains them, and includes them if I force it to stay on that form after a save and dump them to HTML. So... why aren't they there afterwards, in firewall_rules.php or command prompt, like the rest of the saved form contents from that page?

I want to shortcut the work and variable tracing seems a good way to go. So I'm trying to find a way to trace when $config is modified, then in theory all I need to do is run that form in the browser, click save, and look at the trace, to see what happened to the data. Either it was never set properly (scope, etc?) or never saved to $config (validation?), or overwritten (?). So far none of those seem to happen. But they must. And having variable assignment tracing will be helpful for future stuff too.

Gertjan

On line 1092 of /usr/local/www/firewall_rules_edit.php you find the

		if (write_config(gettext("Firewall: Rules - saved/edited a firewall rule."))) {

At that moment, the modified PHP array var config shuld contain all your edits, and are about to be written to the /conf/config.xml file.

See /etc/inc/config.lib.inc line 461 for all the details.
The write_config is well documented, and you'll find reasons ( !! ) why things won't get written to the file /conf/config.xml on the disk.

Now it's a matter of print_r() every line ^^ up until the moment the memory based $config looses your settings (?).

The used function safe_write_file() is also in /etc/inc/config.lib.inc, that the one where the actual fwrite($file ..... ) happens.

stilez

@gertjan - the tips about config.lib.inc might just be helpful enough. And, as you say, print_r the hell out of it, and the safe_file_write function I'll try that later. Thank you!

Still wanna get xdebug working though!! No easy way?

Gertjan

@stilez said in Testing some development - how to install xdebug for 2.4.5-p1?:

No easy way?

I'm confident now that you will let me know ;)