Smokeping on pfSense
-
Great.. Thanks again
-
/usr/sbin/sendmail is not present on the default installation, but if you install arpwatch package, it will be there (linked to /usr/sbin/sm.php)
Interesting idea to try and set it up under vHost..
-
-
Perhaps you forgot:
Finally install Postfix Forwarder via WebGUI.
No, I saw this, just did not realize right away why are you installing Postfix - I don't use it…
Since arpwatch also provides sendmail (using pfSense configured script), it might be easier on the system, unless you really need Postfix.
Also I now wonder if those two packages will conflict with each other because of that. (There are other problems with having sendmail available on pfsense - cron starts emailing output from jobs, I posted on this before).Is there a small guide for vhost in lighttp for pfSense available anywhere? Then I'll have a look …
Well, vHosts package does not have any documentation - there was something before and package has link (https://doc.pfsense.org/index.php/Vhosts) which goes nowhere…
If you want to play around, just install vHosts package, create web site and modify /var/etc/vhosts-http.conf to enable .cgi to be processed with perl and linking /usr/local/smokeping/htdocs/img/ to subfolder under /usr/local/vhosts/<yoursite>.I tried this already and it works fine, the only issue is that vhosts-http.conf will be rebuilt on reboot, so you either need to create your own vhosts-like service or replace vhosts-http.conf on reboot with your own copy...
If I get good solution, I'll try to document steps here.</yoursite>
-
Hey DG,
played around a bit.
What about changing defaults in /usr/local/pkg/vhosts.inc
When you search in this file for "cgi.assign" and replace the 2 places like this:
$tmp .= "cgi.assign = ( ".cgi" => "",\n";
$tmp .= " ".fcgi" => ""\n";
$tmp .= " )\n";Then there won't be an overwrite after reboot.
Also I didn't link to vhosts .. I just set the docroot of the vhost in GUI to ../smokeping/htdocs
I'm not an expert, but this could be a security risk from the vhosts package since you can break out of the docroot folder. No idea if you can travel around filesystem :)
-
Well, yes, you can edit /usr/local/pkg/vhosts.inc to make sure it generates vhosts-http.conf file the way you like it, but I find it a bit awkward and when you upgrade package, it breaks your customizations…
Other options are:-
add script to /usr/local/etc/rc.d/ which would replace vhosts-http.conf from your modified copy and restart service if needed
-
install vHosts package, save /var/etc/zhosts-http.conf and /usr/local/etc/rc.d/zhosts-http.sh somewhere, uninstall vHosts package and restore files
-
copy /var/etc/vhosts-http.conf and /usr/local/etc/rc.d/vhosts-http.sh to files with different name and edit them to create your own version of vHosts
I used [3] in couple of installations already. Any solution requires you to keep track of files and changes done outside of pfSense GUI, but that is expected. If easier management required, those new files can be registered in Filer package, then they will be included in pfSense xml config. I prefer backing all custom files separately, but that's just me.
Another choice needs to be made about using CGI vs FastCGI. I do not see any gain in using FastCGI here, but since smokeping supports it, here you go:
- For CGI, point cgi.assign to perl (and rename smokeping.fcgi to smokeping.cgi):
cgi.assign = ( ".cgi" => "/usr/local/bin/perl" )
- For FastCGI, add this section to fastcgi.server:
".fcgi" => ( "cgi-perl" => ( "socket" => "/var/tmp/lighttpd-fcgi.sock", "bin-path" => "/usr/local/smokeping/htdocs/smokeping.fcgi", "max-procs" => 1, ) )
It is up to you if you want to point your vHosts home folder to actual smokeping folder or link it… Sadly, mod_alias is not included in lighttpd in pfSense, or you would have been able to specify alias.url to point to it...
Other than that and couple of smokeping-related steps in outlined in the first post in this topic, everything works fine so far.
-
-
True that! :(
I only see two "stable" options here:
- Talk to the guys of vHosts package to add fcgi to the cgi.assign
- Stay with apache which doesn't break things (on first sight)
-
- 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
-
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. -
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.
-
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. -
i would agree, but i've been beta testing another package that uses lighttpd and they way pfSense services work; has been causing issues.
-
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. -
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.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"; ?>
-
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!).
-
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.
-
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 :(
-
-
-
-