[pfSense Support] SpamD Broken Behavior Fixed, see attached patch.
filter.inc.patch: necessary for the correct operation of spamd
Table exists but was never populated or used. Fixed.
Table exists but was never populated. Fixed.
Broken rule logic for whitelist entries, either (rdr) or (no rdr). Fixed.
Comments:
I guess no one noticed that the static whitelisting didn't work, since
the same entries would eventually be dynamically whitelisted anyway.
You can observe the broken behavior clearly by whitelisting a test IP
that is known to not be dynamically whitelisted already, then telneting
to any IP behind pfsense on port 25 from the test IP.
Having been whitelisted, you should not be rdr(ed) to spamd. But you are.
The problem was in using as the same table for both static
and dynamic entries. spamlogd removes the entries immediately after
they're loaded.
Blacklisting (via /var/db/blacklist.txt) did not work.
813,822d812
< if(file_exists("/var/db/whitelist.txt"))
< $natrules .= "table persist file
\"/var/db/whitelist.txt\"\n";
< else
< $natrules .= "table persist\n";
< if(file_exists("/var/db/blacklist.txt"))
< $natrules .= "table persist file
\"/var/db/blacklist.txt\"\n";
< else
< $natrules .= "table persist\n";
< $natrules .= "table persist\n";
< $natrules .= "table persist\n";
823a814,821
> $natrules .= "table persist\n";
> $natrules .= "table persist\n";
> $natrules .= "table persist\n";
> if(file_exists("/var/db/whitelist.txt"))
> $natrules .= "table persist file
> \"/var/db/whitelist.txt\"\n";
> $natrules .= "rdr pass on {$wanif} proto tcp from
> to port smtp -> 127.0.0.1 port spamd\n";
> $natrules .= "rdr pass on {$wanif} proto tcp from to
> port smtp -> 127.0.0.1 port spamd\n";
> $natrules .= "rdr pass on {$wanif} proto tcp from
> ! to port smtp -> 127.0.0.1 port spamd\n";
825,832c823,827
<
foreach($config['installedpackages']['spamdsettings']['config'] as $ss)
< $nextmta = $ss['nextmta'];
< if($nextmta <> "")
< $natrules .= "rdr pass on {$wanif} proto tcp from {
} to port smtp -> {$nextmta} port smtp\n";
< else
< $natrules .= "no rdr on {$wanif} proto tcp from
to any port = smtp\n";
< $natrules .= "rdr pass on {$wanif} proto tcp from {
} to port smtp -> 127.0.0.1 port spamd\n";
< $natrules .= "rdr pass on {$wanif} proto tcp from {
! } to port smtp -> 127.0.0.1 port spamd\n";
---
>
> foreach($config['installedpackages']['spamdsettings']['config'] as $ss)
> $nextmta = $ss['nextmta'];
> if($nextmta <> "") {
> $natrules .= "rdr pass on {$wanif} proto tcp from
> to port smtp -> {$nextmta} port smtp\n";
> }
-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] SpamD Broken Behavior Fixed, see attached patch.
Scott Ullrich wrote: Can you please do a diff -rub you want a recursive diff of the whole system? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] SpamD Broken Behavior Fixed, see attached patch.
Scott Ullrich wrote: want a recursive diff of the whole system? No, sorry I was not more clear. Just a diff -rub of filter.inc No, no, I'm unfamiliar with the process. I'm sure you were perfectly clear. Ok, but I'll have to clean up first. A diff -rub in my current setup is messy. I guess I'm working a bit bass ackwards here. I copied the modified file from my production box (1.2.2) to my new 1.2.2 dev VM and diffed it there, removing the additional (dev) entries by hand, leaving only the pertinent. Anyway, I have a standard 1.2.2 vm installing and can do it there when its done.
Re: [pfSense Support] SpamD Broken Behavior Fixed, see attached patch.
Scott Ullrich wrote:
Hey this is great, thank you!
Can you please do a diff -rub and then email the patch as an
attachment to coret...@pfsense.org and I will get it promptly
committed.
Done.
I've also attached a patch for spamd_db.php that makes the GUI more
accurate and informative in the db accounting.
I'd also like to modify the package to add options for enabling
spamd-setup -b and spamlogd -I options which I use and should be
selectable I think.
There should also be a blacklist tab for editing the blacklist.txt file,
just as there is with the whitelist.txt\
~Tim
--- filter.inc_1.2.2-REL2009-06-18 22:09:05.0 -0400
+++ filter.inc_1.2.2-REL-spamd-fix 2009-06-18 21:35:09.0 -0400
@@ -810,21 +810,26 @@
/* is SPAMD insalled? */
if (is_package_installed("spamd") == 1) {
$natrules .= "\n# spam table \n";
-
+ if(file_exists("/var/db/whitelist.txt"))
+ $natrules .= "table persist file
\"/var/db/whitelist.txt\"\n";
+ else
$natrules .= "table persist\n";
+ if(file_exists("/var/db/blacklist.txt"))
+ $natrules .= "table persist file
\"/var/db/blacklist.txt\"\n";
+ else
$natrules .= "table persist\n";
$natrules .= "table persist\n";
- if(file_exists("/var/db/whitelist.txt"))
- $natrules .= "table persist file
\"/var/db/whitelist.txt\"\n";
- $natrules .= "rdr pass on {$wanif} proto tcp from
to port smtp -> 127.0.0.1 port spamd\n";
- $natrules .= "rdr pass on {$wanif} proto tcp from to
port smtp -> 127.0.0.1 port spamd\n";
- $natrules .= "rdr pass on {$wanif} proto tcp from
! to port smtp -> 127.0.0.1 port spamd\n";
+ $natrules .= "table persist\n";
+
if($config['installedpackages']['spamdsettings']['config'])
foreach($config['installedpackages']['spamdsettings']['config'] as $ss)
$nextmta = $ss['nextmta'];
- if($nextmta <> "") {
- $natrules .= "rdr pass on {$wanif} proto tcp from
to port smtp -> {$nextmta} port smtp\n";
- }
+ if($nextmta <> "")
+$natrules .= "rdr pass on {$wanif} proto tcp from {
} to port smtp -> {$nextmta} port smtp\n";
+ else
+ $natrules .= "no rdr on {$wanif} proto tcp from
to any port = smtp\n";
+ $natrules .= "rdr pass on {$wanif} proto tcp from {
} to port smtp -> 127.0.0.1 port spamd\n";
+ $natrules .= "rdr pass on {$wanif} proto tcp from {
! } to port smtp -> 127.0.0.1 port spamd\n";
}
/* load balancer anchor */
--- spamd_db.php_1.2.2-REL 2009-06-18 01:56:34.0 -0400
+++ spamd_db.php_1.2.2-REL-spamd-fix2009-06-18 11:15:14.0 -0400
@@ -176,17 +176,18 @@
include("head.inc");
if(file_exists("/var/db/whitelist.txt"))
- $whitelist_items = `cat /var/db/whitelist.txt | wc -l`;
+ $static_whitelist_items = `pfctl -T show -t whitelist | wc -l`;
else
$whitelist_items = 0;
if(file_exists("/var/db/blacklist.txt"))
- $blacklist_items = `cat /var/db/blacklist.txt | wc -l`;
+ $static_blacklist_items = `pfctl -T show -t blacklist | wc -l`;
else
$blacklist_items = 0;
// Get an overall count of the database
$spamdb_items = `/usr/local/sbin/spamdb | wc -l`;
+$accounted_items = $spamdb_items + $static_whitelist_items +
$static_blacklist_items;
// Get blacklist and whitelist count from database
$spamdb_white = `/usr/local/sbin/spamdb | grep WHITE | wc -l`;
@@ -194,8 +195,8 @@
$spamdb_grey = `/usr/local/sbin/spamdb | grep GREY | wc -l`;
// Now count the user contributed whitelist and blacklist count
-$whitelist_items = $whitelist_items + $spamdb_white;
-$blacklist_items = $blacklist_items + $spamdb_black;
+$whitelist_items = $static_whitelist_items + $spamdb_white;
+$blacklist_items = $static_blacklist_items + $spamdb_black;
?>
@@ -447,10 +448,11 @@
Database totals:
";
- echo "{$blacklist_items} total items in the
blacklist.";
+ echo "{$whitelist_items} total items in the whitelist:
{$spamdb_white} dynamic, {$static_whitelist_items} static
(/var/db/whitelist.txt).";
+ echo "{$blacklist_items} total items in the blacklist:
{$spamdb_black} dynamic, {$static_blacklist_items} static
(/var/db/blacklist.txt).";
echo "{$spamdb_grey} total items in the greylist.";
echo "{$spamdb_items} total items in the SpamDB.";
+ echo "{$accounted_items} total accounted items.";
?>
-
To
Re: [pfSense Support] SpamD Broken Behavior Fixed, see attached patch.
Scott Ullrich wrote: All you need to do is use the -rub option with diff the next time. When you try to apply your patch it will not work. I thought there might be a problem. When I tested the patch it complained but worked out anyway. So I figured it was ok. Will -rub em from now on.
[pfSense Support] Patch: DHCP Boot Server Options (Option 66 TFTP Boot Server).
DHCP Boot Server Options in pfsense are currently implemented only via the next-server option method, requiring the server IP and boot file. This works great... if you only have one device to netboot. Or if you have a complex dhcpd.conf serving different images according to the requesting MAC. But that's not an option on pfsense and doesn't make sense anyway. Most commonly these days, DHCP Boot Server Options are used for IP Phones--to deliver their config files and update firmware. Most IP phone systems these days that I've seen (currently using Shoretel) prefer the option 66 method, only requiring the server IP. The boot server (phone system) then determines what files to serve based on the requesting MAC. Its much easier to administer boot images on the boot server (phone system) than via DHCP. And makes more sense. I originally made these modifications to a pfsense router at a remote site of ours to address this issue for their phones--which were not getting their expected firmware updates. I thought I ought to share the mod with you all. Its very minor. It only adds boot-server option 66 method if you leave out the file image, and changes text in the GUI indicating as much. --- services_dhcp.php.orig 2009-06-27 03:21:55.0 -0400 +++ services_dhcp.php 2009-06-27 03:09:53.0 -0400 @@ -585,12 +585,12 @@ > Enables network booting. - - Enter the IP address from the network boot server. +IP Address of boot server. + This is used for both next-server and option 66 (boot-server) methods. - - Enter the filename used for network booting. - Note: You need both a filename and a boot server configured for this to work! +Boot image filename. + Note: You need both a filename and a boot server configured for the next-server option method to work! + Leave blank for option 66 (boot-server) method. --- services.inc.orig 2009-06-27 03:09:53.0 -0400 +++ services.inc2009-06-27 03:09:53.0 -0400 @@ -115,6 +115,7 @@ $dhcpdconf = <<- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Patch: DHCP Boot Server Options (Option 66 TFTP Boot Server).
I had never successfully used the pfsense boot server option previously,
had anyone else?
I just noticed a typo in a the existing line that appends the filename
to the next-server options to be written.
I don't think it would have worked properly.
Attached is my previous patch now also including a correction for that
error as well.
Tim A. wrote:
DHCP Boot Server Options in pfsense are currently implemented only via
the next-server option method, requiring the server IP and boot file.
This works great... if you only have one device to netboot. Or if you
have a complex dhcpd.conf serving different images according to the
requesting MAC. But that's not an option on pfsense and doesn't make
sense anyway.
Most commonly these days, DHCP Boot Server Options are used for IP
Phones--to deliver their config files and update firmware. Most IP
phone systems these days that I've seen (currently using Shoretel)
prefer the option 66 method, only requiring the server IP. The boot
server (phone system) then determines what files to serve based on the
requesting MAC.
Its much easier to administer boot images on the boot server (phone
system) than via DHCP. And makes more sense.
I originally made these modifications to a pfsense router at a remote
site of ours to address this issue for their phones--which were not
getting their expected firmware updates.
I thought I ought to share the mod with you all.
Its very minor.
It only adds boot-server option 66 method if you leave out the file
image, and changes text in the GUI indicating as much.
--- services.inc.orig Sat Jun 27 04:09:53 2009
+++ services.incSat Jun 27 04:35:02 2009
@@ -115,6 +115,7 @@
$dhcpdconf = << "") &&
($dhcpifconf['filename'] <> "")) {
$dhcpdconf .= " next-server
{$dhcpifconf['next-server']};\n";
- $dhcpdconf .= " filename
\"{$dhcpifconf['filename']}\";\n";
+ $dhcpdconf .= " filename
\"{$dhcpifconf['filename']};\"\n";
+ }
+/* Add option 066 TFTP boot server */
+ else {
+ $dhcpdconf .= " boot-server
\"{$dhcpifconf['next-server']};\"\n";
}
}
$dhcpdconf .= <<-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Patch: DHCP Boot Server Options (Option 66 TFTP Boot Server).
I apologize. It's my error. The colons here aren't for PHP, but for
dhcpd.conf duh.
My original patch was in error. It is corrected herein and the previous
"correction" removed.
Tim A. wrote:
I had never successfully used the pfsense boot server option
previously, had anyone else?
I just noticed a typo in a the existing line that appends the filename
to the next-server options to be written.
I don't think it would have worked properly.
Attached is my previous patch now also including a correction for that
error as well.
Tim A. wrote:
DHCP Boot Server Options in pfsense are currently implemented only
via the next-server option method, requiring the server IP and boot
file. This works great... if you only have one device to netboot. Or
if you have a complex dhcpd.conf serving different images according
to the requesting MAC. But that's not an option on pfsense and
doesn't make sense anyway.
Most commonly these days, DHCP Boot Server Options are used for IP
Phones--to deliver their config files and update firmware. Most IP
phone systems these days that I've seen (currently using Shoretel)
prefer the option 66 method, only requiring the server IP. The boot
server (phone system) then determines what files to serve based on
the requesting MAC.
Its much easier to administer boot images on the boot server (phone
system) than via DHCP. And makes more sense.
I originally made these modifications to a pfsense router at a remote
site of ours to address this issue for their phones--which were not
getting their expected firmware updates.
I thought I ought to share the mod with you all.
Its very minor.
It only adds boot-server option 66 method if you leave out the file
image, and changes text in the GUI indicating as much.
--- services.inc.orig 2009-06-27 03:09:53.0 -0400
+++ services.inc2009-06-27 05:59:54.0 -0400
@@ -115,6 +115,7 @@
$dhcpdconf = << "") {
+$dhcpdconf .= " boot-server
\"{$dhcpifconf['next-server']}\";\n";
+}
}
$dhcpdconf .= <<-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
[pfSense Support] Patch and ISO: New Feature -- Auto Configuring Interfaces
Attached a patch against 1.2.3-rc2 adding support for auto configuring
interfaces.
By enabling sshd in the default config.xml on the Live CD installer,
this eliminates many headaches for installs:
No monitor / keyboard / mouse required.
No console cable required.
Install to headless boxes that don't even have console ports!
No more crackin open your box to screw with CF cards and /etc/fstab
nightmares (for being installed to a /dev/device that no longer exists!).
Just plug-in, turn it on and ssh to the default IP.
This is a link to an ISO built with this patch and my previously
submitted DHCP Server patch.
http://techneck.goldenpath.org/pfsense/pfSense_1.2.3-R2_RELENG_7_2_techneck_patches.iso
The new code will pause to allow interruption for manual assignment. Any
keyboard input will interrupt the procedure.
But if left unattended the code will timeout to begin the automated process.
The code assigns interfaces in the order they were discovered, LAN, WAN,
OPT1, OPT2, etc...
If only one interface exists and is vlan capable, the code with create
vlan0 tagged VLAN1.
But this will invariably be assigned to WAN as LAN is assigned first and
obviously the parent NIC is discovered before the vlan0.
This is appropriate behavior though given the undesirable situation of
having only 1 NIC, and installation priorities.
It is appropriate because it is more likely that the typical user is not
actually prepared to connect to VLANs and his priority is to connect to
the LAN interface to install and configure his box
~Tim
2.9
nervecenter
normal
pfSense
local
admin
$1$dSJImFph$GvZ7.1UbuWu.Yb8etC0re.
Etc/UTC
300
0.pfsense.pool.ntp.org
http
yes
yes
vr0
192.168.1.1
24
100
Mb
vr1
dhcp
100
Mb
dyndns
192.168.1.100
192.168.1.199
public
pass
Default LAN -> any
lan
lan
0
*
*
*
*
root
/usr/bin/nice -n20 newsyslog
1,31
0-5
*
*
*
root
/usr/bin/nice -n20 adjkerntz -a
1
3
1
*
*
root
/usr/bin/nice -n20 /etc/rc.update_bogons.sh
*/60
*
*
*
*
root
/usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 sshlockout
1
1
*
*
*
root
/usr/bin/nice -n20 /etc/rc.dyndns.update
*/60
*
*
*
*
root
/usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 virusprot
*/5
*
*
*
*
root
/usr/local/bin/checkreload.sh
*/5
*
*
*
*
root
/etc/ping_hosts.sh
*/140
*
*
*
*
root
/usr/local/sbin/reset_slbd.sh
siproxd
http://siproxd.sourceforge.net/
Proxy for handling NAT of multiple SIP devices to a single public IP.
Services
http://www.pfsense.com/packages/config/siproxd.xml
http://files.pfsense.org/packages/7/All/
siproxd-0.7.0_1.tbz
http://doc.pfsense.org/index.php/Siproxd_package
0.7.2
Beta
1.2.1
siproxd.xml
siproxd
Modify siproxd users and settings.
Services
/pkg_edit.php?xml=siproxd.xml&id=0
siproxd
siproxd.sh
siproxd
--- config.inc.old 2009-07-05 10:18:55.0 -0400
+++ config.inc 2009-07-05 11:39:34.0 -0400
@@ -1285,6 +1285,95 @@
echo < $vface) {
+ $vlan['if'] = $vface;
+ $vlan['tag'] =
Re: [pfSense Support] Patch and ISO: New Feature -- Auto Configuring Interfaces
Thanks for the kind words, guys. I'm thinking of a "gotcha" though. I need to add awareness of live CD or normal operations to the function though. This is all in the set_networking_interfaces_ports() function. Which is called from several places, like, during boot up and from the rc.initial screen that runs during normal operations. I'm thinking of the "oops" potential of a production box, and an errant key press hits #2 and for some reason or another the user doesn't notice and doesn't exit the count down. Boom. I need to poke around and find the existing LiveCD "Awareness" method and only enable the feature therein, or if interface mismatch on bootup. I'm sure its here somewhere. Matt Hohman wrote: This would have saved my bacon a couple months ago... Thanks for the great add. Thanks, Matt Hohman New Heights Church Sent from my iPhone On Jul 5, 2009, at 3:28 PM, Tim Nelson wrote: Tim A. wrote: Attached a patch against 1.2.3-rc2 adding support for auto configuring interfaces. By enabling sshd in the default config.xml on the Live CD installer, this eliminates many headaches for installs: No monitor / keyboard / mouse required. No console cable required. Install to headless boxes that don't even have console ports! No more crackin open your box to screw with CF cards and /etc/fstab nightmares (for being installed to a /dev/device that no longer exists!). Just plug-in, turn it on and ssh to the default IP. This is a link to an ISO built with this patch and my previously submitted DHCP Server patch. http://techneck.goldenpath.org/pfsense/pfSense_1.2.3-R2_RELENG_7_2_techneck_patches.iso The new code will pause to allow interruption for manual assignment. Any keyboard input will interrupt the procedure. But if left unattended the code will timeout to begin the automated process. The code assigns interfaces in the order they were discovered, LAN, WAN, OPT1, OPT2, etc... If only one interface exists and is vlan capable, the code with create vlan0 tagged VLAN1. But this will invariably be assigned to WAN as LAN is assigned first and obviously the parent NIC is discovered before the vlan0. This is appropriate behavior though given the undesirable situation of having only 1 NIC, and installation priorities. It is appropriate because it is more likely that the typical user is not actually prepared to connect to VLANs and his priority is to connect to the LAN interface to install and configure his box ~Tim +1 for you. This looks like a great and much needed feature. Thanks! --Tim - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Re: Patch and ISO: New Feature -- Auto Configuring Interfaces
Chris Buechler wrote: On Sun, Jul 5, 2009 at 4:23 PM, Tim A. wrote: Attached a patch against 1.2.3-rc2 adding support for auto configuring interfaces. That's definitely a nice feature, though only suitable for addition to 2.0, so we'll need a patch for 2.0. The only thing from your description that needs to change is the auto-assignment with one interface, 2.0 will let you assign only WAN and treat it basically like LAN with a default gateway for appliance purposes, so if there is only one interface it needs to only assign WAN. Thanks! Aye aye, Captain! On it. I usually tend towards the stable stuff but pfSense has long been a favorite interest of mine and if I can contribute something towards its advancement, it'll be my honor. I'll setup a 2.0 dev environment and take a poke at it. I'll post results as soon as I have em.
Re: [pfSense Support] Patch and ISO: New Feature -- Auto Configuring Interfaces
Ermal Luçi wrote: To me this is a hack and not a feature. Technically speaking: "Feature" is defined in effect. "Hack" is defined in method. So both terms are appropriate here and not mutually exclusive. pfSense itself is an ultimate Hack conglomerate, gluing together IMO some of the best the BSDs have to offer. This is actually one of its strong points. If there were anything too original here, Cisco or Juniper might have bought it out by now. There is a better way to do this things than kludge things here and there in the code. I share the sentiment. I felt a little guilty actually. But the value of the feature pressed upon me. And the existing code was done in the same fashion. Most the code in this patch is actually reused from other areas within the *.inc files. I just restructured it and added some logic. In general the *.inc files disturb me a little but their not that bad. There are a lot of useful hacks / code repeated, embedded in monolithic functions that could be extracted and generalized into their own functions. Rewriting the whole thing is both tempting and daunting. I haven't looked at 2.0 yet, but I'm guessing a lot of clean up is going on there. The right fix was proposed once and not everybody liked the POLA breaking. I missed that episode. POLA? Either way I would not like to see this in pfSense rather than the other solution which would allow installing pfSense from the gui after auto-magically booting the livecd. Actually, thats something I considered and I do intend to work on: Installation via the GUI. But, IMO, the GUI should be kept minimal. Reusing existing proven code / methods as much as possible. So even that would be via an SSH applet. Or we could just make the whole system Lua based and deploy, operate and monitor our pfSense boxes from a WoW addon while plowing through Ulduar =D Now THAT would be a sweet hack, lol. However, Auto Configuring Interfaces is still a prerequisite of that feature / hack. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense Support] Understanding 2.0
I don't get it. Sure there's a lot of features people want to add. And the answer is typically, "2.0". But what is the major platform difference for this major revision? I just built HEAD (2.0 on 7_2) and... umm... I like 1.2.3, at least it works. This is so broken and as far as I can tell, most of its the same anyway. Why not just add new features / fix things on whats already working so well? I'm trying RELENG_2_0 now, maybe that'll be more encouraging. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Understanding 2.0
Scott Ullrich wrote: On Tue, Jul 7, 2009 at 12:27 PM, Tim A. wrote: I don't get it. Sure there's a lot of features people want to add. And the answer is typically, "2.0". But what is the major platform difference for this major revision? I just built HEAD (2.0 on 7_2) and... umm... I like 1.2.3, at least it works. Huh? This is so broken and as far as I can tell, most of its the same anyway. Why not just add new features / fix things on whats already working so well? I'm trying RELENG_2_0 now, maybe that'll be more encouraging. Use the official snapshots -- they work. Scott Sorry, not trying to discredit it. Just trying to understand it. I think the major difference is the CoreGUI2? From what I'm reading this is a major improvement. I rarely even look at the GUI code though, so sorry I over looked that. Same principle could be applied to the underlaying system management interface though. Thats where I've been sticking my nose and thinking "sheesh". Its good stuff, but like Ermal mentioned, theres a lot of kludging code together going on in there, getting kind of clunky. A parameter system / callback driven approach to a rewrite would clean it up a lot.
Re: [pfSense Support] Understanding 2.0
apiase...@midatlanticbb.com wrote: It was always my understanding that pfsense stability came before features. I don't mind that, because i would rather have a product that works 100% of the time, without the features i want. Rather then a product that works 50% of the time, with all the features I want. Adam No no, it was my fault for building HEAD. I knew I could be in for trouble. I was just disappointed and wanted to understand the drive behind 2.0. I built RELENG_2_0 and all is so far so good. The underlying system is mostly the same with some fixes. But this GUI is AWSOME! So smooth and polished. I didn't understand what the major change was that justified the major revision. 2.0 is all about the CoreGUI code. I think they did a clean rewrite. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Understanding 2.0
Bill Marquette wrote:
On Tue, Jul 7, 2009 at 11:27 AM, Tim A. wrote:
I don't get it. Sure there's a lot of features people want to add. And the
answer is typically, "2.0".
But what is the major platform difference for this major revision?
I just built HEAD (2.0 on 7_2) and... umm... I like 1.2.3, at least it
works.
This is so broken and as far as I can tell, most of its the same anyway.
Why not just add new features / fix things on whats already working so well?
I'm trying RELENG_2_0 now, maybe that'll be more encouraging.
Are you sure you are building from git? RELENG_2_0 doesn't exist in
git, we haven't branched it, it's the 'master' branch. And CVS HEAD
got ditched for a reason...it didn't work, was going to take WAY to
much effort to fix and the 1.x tree worked fine, so when 1.2 branched,
we started calling the new head 2.0. It's a significant change in
that it has full blown user permissions/roles, a fully reworked
traffic shaper, dashboard improvements, and lots of work in DRYing up
the UI (by no means is this work anywhere near complete). I'm sure
I'm missing numerous other items, but it's a much larger leap from 1.2
-> 2.0 than 1.1 -> 1.2 was in terms of features/functionality. At the
end of the day, version numbers don't mean anything anyway, don't get
yourself hung up on 1.1, 1.2, 2.0, we could have just as easily called
1.2 pfSense 6.2 since it was FreeBSD 6.2 based, versions in software
are somewhat arbitrary.
--Bill
Thank you for the explanation, Bill. That clears up a lot.
With "RELENG_2_0", I'm referring to the the builder tools and the
set_version.sh tag, it sets:
RELENG_2_0)
echo ">>> Setting builder environment to use RELENG_2_0 ..."
export FREEBSD_VERSION="7"
export FREEBSD_BRANCH="RELENG_7_2"
export SUPFILE="${BUILDER_TOOLS}/builder_scripts/RELENG_7_2-supfile"
export PFSENSE_VERSION=2.0-ALPHA-ALPHA
export PFSENSETAG=RELENG_2_0
export PFSPATCHDIR=${BUILDER_TOOLS}/patches/RELENG_7_2
export
PFSPATCHFILE=${BUILDER_TOOLS}/builder_scripts/patches.RELENG_7_2
export
CUSTOM_COPY_LIST="${BUILDER_TOOLS}/builder_scripts/copy.list.RELENG_2"
export PFSPORTSFILE=buildports.RELENG_2_0
set_items
;;
It also has a HEAD tag. That built a broken ISO yesterday.
The RELENG_2_0 tag builds a good ISO. I'm using it now on a test
network. And, yea, the GUI looks real exciting..
Re: [pfSense Support] Understanding 2.0
Tim A. wrote: I don't get it. Sure there's a lot of features people want to add. And the answer is typically, "2.0". But what is the major platform difference for this major revision? I just built HEAD (2.0 on 7_2) and... umm... I like 1.2.3, at least it works. This is so broken and as far as I can tell, most of its the same anyway. Why not just add new features / fix things on whats already working so well? I'm trying RELENG_2_0 now, maybe that'll be more encouraging. So, to ultimately answer myself concerning "Understanding 2.0", or more generally understanding pfSense development, for anyone else who might be interested: Besides Bill's explanations in the preceding post, 1. Learn git 2. Read / Learn / Familiarize yourself with: http://devwiki.pfsense.org/ A lot of info / tutorials here https://rcs.pfsense.org/ Gitorious http://redmine.pfsense.org/ The Project Management system Git's got me feeling all excited and bubbly. It's like "Hello World" all over again. This is going to be a long term love affair, lol. One thing thats been nagging at me, probably another stupid question but here goes: cscope is one of my favorite tools for finding my way around a bunch code. Is there anything similar to that for php? - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Re: Patch and ISO: New Feature -- Auto Configuring Interfaces
Chris Buechler wrote:
On Sun, Jul 5, 2009 at 4:23 PM, Tim A. wrote:
Attached a patch against 1.2.3-rc2 adding support for auto configuring
interfaces.
That's definitely a nice feature, though only suitable for addition to
2.0, so we'll need a patch for 2.0. The only thing from your
description that needs to change is the auto-assignment with one
interface, 2.0 will let you assign only WAN and treat it basically
like LAN with a default gateway for appliance purposes, so if there is
only one interface it needs to only assign WAN.
Thanks!
Attached a patch against 2.0 adding support for auto configuring interfaces.
This patch is done with -rub. So, you wont see the white space but note
that there's a significant block of the original code that should be
indented with this.
I reworked it to be less clunky and more POLS. Also, I'm learning more
about pfsense internals and the auto interface feature automatically
turns on sshd if it kicks in.
So, no need to worry about the config file.
I'll update the 1.2 patch later with these improvements as well.
By the way. I've started using git, and its very cool. I created an
account and added my key to rcs.pfsense.org.
I tried to push this to the repo but it keeps saying not allowed.
Are you guys only using that internally?
--- a/etc/inc/config.inc2009-07-14 16:39:50.0 -0400
+++ b/etc/inc/config.inc2009-07-14 14:30:35.0 -0400
@@ -790,6 +790,12 @@
$iflist = get_interface_list();
+/* Function flow is based on $key and $auto_assign or the lack thereof */
+ $key = null;
+
+ if ((ereg("cdrom", $g['platform'])) || is_interface_mismatch())
+ $auto_assign = true;
+
echo << $ifa) {
echo sprintf("% -16s%s%s\t%s\n", $iface, $ifa['mac'],
@@ -807,6 +813,14 @@
}
}
+ if ($auto_assign) {
+ echo <</dev/null\`; echo
\$KEY`);
+ `/bin/stty icanon`;
+ if ($key == '')
+ unset($key);
+ // Decrement our timeout value
+ $timeout--;
+ // If we have reached 0 exit and continue on
+ if ($timeout == 0)
+ break;
+ }
+ } else
+ $key = chop(fgets($fp));
+
+
+ if (!isset($key)) { // Auto Assign Interfaces
+ $optif = array();
+ $i = $j = 0;
+ echo "\n\n";
+ foreach ($iflist as $iface => $ifa) {
+ if ($i > 1) {
+ $optif[$j] = $iface;
+ echo "Assigned OPT" . ($j+1) . " to :
$optif[$j] \n";
+ $i++;
+ $j++;
+ }
+ elseif ($i == 1) {
+ $lanif = $iface;
+ echo "Assigned LAN to : $lanif \n";
+ $i++;
+ }
+ elseif ($i == 0) {
+ $wanif = $iface;
+ echo "Assigned WAN to : $wanif \n";
+ $i++;
+ }
+ }
+
+ $config['system']['enablesshd'] = 'enabled';
+ $key = 'y';
+
+ } else {//Manually assign interfaces
+ if (in_array($key, array('y', 'Y')))
vlan_setup();
if (is_array($config['vlans']['vlan']) &&
count($config['vlans']['vlan'])) {
@@ -953,15 +1014,17 @@
echo "OPT" . ($i+1) . " -> " . $optif[$i] . "\n";
}
-echo <<-
To unsubscribe, e-mail: support-unsubscr...@pfsense.com
For additional commands, e-mail: support-h...@pfsense.com
Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] Re: Patch and ISO: New Feature -- Auto Configuring Interfaces
Chris Buechler wrote: On Tue, Jul 14, 2009 at 6:08 PM, Tim A. wrote: I tried to push this to the repo but it keeps saying not allowed. Are you guys only using that internally? You can only push to your own clones unless you're an authorized committer, we don't let just anybody push changes into official repos (and other branches like RELENG_1_2 for 1.2.3 are much more restricted than mainline/2.0). Scott will get you setup so you can push this to mainline. Thanks! I thought that might be the case, but I didn't see any feature that allowed for the creation of my own repositories. I looked at setting up my own server, with the gitweb package. But this rcs thing looks like the place you want to consolidate.
Re: [pfSense Support] SpamD Broken Behavior Fixed, see attached patch.
Tim A. wrote:
Scott Ullrich wrote:
Hey this is great, thank you!
Can you please do a diff -rub and then email the patch as an
attachment to coret...@pfsense.org and I will get it promptly
committed.
Done.
I've also attached a patch for spamd_db.php that makes the GUI more
accurate and informative in the db accounting.
I'd also like to modify the package to add options for enabling
spamd-setup -b and spamlogd -I options which I use and should be
selectable I think.
There should also be a blacklist tab for editing the blacklist.txt
file, just as there is with the whitelist.txt\
~Tim
I am disappointed to see SpamD was removed from the packages rather than
fixed.
Now I need it.
How do I get it?
I can fix it after its installed, but I'm not sure how to make the
package to get it installed
--- filter.inc_1.2.2-REL2009-06-18 22:09:05.0 -0400
+++ filter.inc_1.2.2-REL-spamd-fix 2009-06-18 21:35:09.0 -0400
@@ -810,21 +810,26 @@
/* is SPAMD insalled? */
if (is_package_installed("spamd") == 1) {
$natrules .= "\n# spam table \n";
-
+ if(file_exists("/var/db/whitelist.txt"))
+ $natrules .= "table persist file
\"/var/db/whitelist.txt\"\n";
+ else
$natrules .= "table persist\n";
+ if(file_exists("/var/db/blacklist.txt"))
+ $natrules .= "table persist file
\"/var/db/blacklist.txt\"\n";
+ else
$natrules .= "table persist\n";
$natrules .= "table persist\n";
- if(file_exists("/var/db/whitelist.txt"))
- $natrules .= "table persist file
\"/var/db/whitelist.txt\"\n";
- $natrules .= "rdr pass on {$wanif} proto tcp from
to port smtp -> 127.0.0.1 port spamd\n";
- $natrules .= "rdr pass on {$wanif} proto tcp from to
port smtp -> 127.0.0.1 port spamd\n";
- $natrules .= "rdr pass on {$wanif} proto tcp from
! to port smtp -> 127.0.0.1 port spamd\n";
+ $natrules .= "table persist\n";
+
if($config['installedpackages']['spamdsettings']['config'])
foreach($config['installedpackages']['spamdsettings']['config'] as $ss)
$nextmta = $ss['nextmta'];
- if($nextmta <> "") {
- $natrules .= "rdr pass on {$wanif} proto tcp from
to port smtp -> {$nextmta} port smtp\n";
- }
+ if($nextmta <> "")
+$natrules .= "rdr pass on {$wanif} proto tcp from {
} to port smtp -> {$nextmta} port smtp\n";
+ else
+ $natrules .= "no rdr on {$wanif} proto tcp from
to any port = smtp\n";
+ $natrules .= "rdr pass on {$wanif} proto tcp from {
} to port smtp -> 127.0.0.1 port spamd\n";
+ $natrules .= "rdr pass on {$wanif} proto tcp from {
! } to port smtp -> 127.0.0.1 port spamd\n";
}
/* load balancer anchor */
--- spamd_db.php_1.2.2-REL 2009-06-18 01:56:34.0 -0400
+++ spamd_db.php_1.2.2-REL-spamd-fix2009-06-18 11:15:14.0 -0400
@@ -176,17 +176,18 @@
include("head.inc");
if(file_exists("/var/db/whitelist.txt"))
- $whitelist_items = `cat /var/db/whitelist.txt | wc -l`;
+ $static_whitelist_items = `pfctl -T show -t whitelist | wc -l`;
else
$whitelist_items = 0;
if(file_exists("/var/db/blacklist.txt"))
- $blacklist_items = `cat /var/db/blacklist.txt | wc -l`;
+ $static_blacklist_items = `pfctl -T show -t blacklist | wc -l`;
else
$blacklist_items = 0;
// Get an overall count of the database
$spamdb_items = `/usr/local/sbin/spamdb | wc -l`;
+$accounted_items = $spamdb_items + $static_whitelist_items +
$static_blacklist_items;
// Get blacklist and whitelist count from database
$spamdb_white = `/usr/local/sbin/spamdb | grep WHITE | wc -l`;
@@ -194,8 +195,8 @@
$spamdb_grey = `/usr/local/sbin/spamdb | grep GREY | wc -l`;
// Now count the user contributed whitelist and blacklist count
-$whitelist_items = $whitelist_items + $spamdb_white;
-$blacklist_items = $blacklist_items + $spamdb_black;
+$whitelist_items = $static_whitelist_items + $spamdb_white;
+$blacklist_items = $static_blacklist_items + $spamdb_black;
?>
@@ -447,10 +448,11 @@
Database totals:
";
- echo "{$blacklist_items} total items in the
blackl
[pfSense Support] VPN NAT for hiding local addresses
Hello, I am trying to track down some info on how to hide my private IP's when connecting to a remote VPN using pfSense. Can anyone help with configuration or give me some links to something that may help? Apparently the VPN I am connecting to won't allow private IP's as they have thousands of tunnels and conflicts always happen. Thanks Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
