Smokeping on pfSense

Cino

Talk to the guys of vHosts package to add fcgi to the cgi.assign

I don't think there is a package maintainer for vhost anymore. Its an easy change to the code to make it happen but vhost doesn't have a pbi; this changes everything. You see vhost basically uses lighttpd that comes with pfSense. You can add more to it but if its not included in the base pfSense install. a pbi would need to be created. In this case, perl would need to in its pbi to meet the pfSense Package Standard (if there is sure a thing).

To assist with the firmware updates and such, copy the vhosts.inc file, and edit the original file. You can create a patch file between the 2 files. Then use the system patch package and add the patch to it. You can have it auto apply on reboots which would take care of firmware updates where packages overwrite the changes you made

dgcom

If we would be talking about just vHosts package, patching pfSense would have made sense.
But we are talking about Smokeping - the whole separate package, installed from outside - in this case, adding two additional files to maintain (service start script and lighttpd config file) is easy.
I think that having new package for Smokeping with its own instance of lighttpd makes more sense.

Cino

I agree.. I have seen issues where stopping lighttpd could cause issues with the web-gui since they use the same same binary name… easy workaround is to link lighttpd to lets say lighttpd-smokeping in the same directory.

dgcom

There should be no issue stopping service using executable with the same name, that's why pids exist.
And copying lighttpd might be asking for trouble with future updates.

Cino

i would agree, but i've been beta testing another package that uses lighttpd and they way pfSense services work; has been causing issues.

dgcom

Well, could be an issue with that beta version of the package too :)
There are several things can go wrong, but if stuff coded properly, there should be no issue.

BBcan177

@dgcom:

There should be no issue stopping service using executable with the same name, that's why pids exist.
And copying lighttpd might be asking for trouble with future updates.

@dgcom:

Well, could be an issue with that beta version of the package too :)
There are several things can go wrong, but if stuff coded properly, there should be no issue.

In pfSense, the option to "Restart WebConfigurator" runs the following code below. So it will kill all pids that use "lighttpd".

sigkillbyname("lighttpd", "KILL");

A way around this, without any significant changes, is to create a link to the lighttpd executable like so: (This is also not a copy of the file. So its not affected by upgrades etc…)

link ("/usr/local/sbin/lighttpd", "/usr/local/sbin/lighttpd_spipe");

and then use this new link as the Service name for Smokepiping without it being effected by a webConfigurator restart. I don't use vHosts, but I think it suffers from this webconfigurator restart issue as its using the same lighttpd executable.

/etc/rc.restart_webgui


#!/usr/local/bin/php -f

require("config.inc");
require("functions.inc");
require("shaper.inc");
require("captiveportal.inc");
require_once("rrd.inc");

echo "Restarting webConfigurator...";

sigkillbyname("lighttpd", "KILL");

while (is_process_running("lighttpd")) {
        echo '.';
        sleep(1);
}

system_webgui_start();

captiveportal_init_webgui();

enable_rrd_graphing();

echo " done.\n\n";

?>

dgcom

@BBcan177:

In pfSense, the option to "Restart WebConfigurator" runs the following code below. So it will kill all pids that use "lighttpd".

Boo, did not realize that the bug is in pfSense itself :( Didn't restart WebConfigurator lately, so never noticed this.

Thank you for clarification. And yes, link in this case would help (but not copy!).

BBcan177

@dgcom:

@BBcan177:

In pfSense, the option to "Restart WebConfigurator" runs the following code below. So it will kill all pids that use "lighttpd".

Boo, did not realize that the bug is in pfSense itself :( Didn't restart WebConfigurator lately, so never noticed this.

Thank you for clarification. And yes, link in this case would help (but not copy!).

Well technically its not a "bug"… I think its best that they kill "Lighttpd" by name instead of trying to kill by pid. They would want a foolproof way of doing that and killbyname does it perfectly... So i think this work around is a good approach and I think cleaner.

dgcom

So you mean - killbyname in case something happened to pid file?
I wouldn't do it like that, but I am not developing pfSense. If developers need to killbyname, they should be using link with different name themselves :)

I am not here to judge this. If that's how it is done currently, we'll use workaround, I just don't like that many workarounds around pfSense :(