Packages wishlist?
-
Well first that code is wrong there now is get_configured_interface_list() or get_configured_interface_with_descr() as you can see we are pushing 1.3 to have APIs to facilitate most of things.
Form the interface list to the other infos.Hehe Then it should be corrected in status_interfaces.php ;D
-
Where are you reading this?
-
ok my mistake, that was 1.2.1 not 1.3 as i thought.
-
From a semi-outsider's viewpoint, I do think some developer doc and an up-to-date API would be a HUGE plus for the project.
I've been using pf for over 2 years on several projects, and although I don't have a lot of time on my hands, I happen to be an experienced PHP programmer, and I do think I could contribute to the project with some basic doc like that.
It would take me 2 weeks now to read through the source and figure out the structure you are using, the guidelines you follow, the functions that are available, etc. With some basic how-to and a reference API, I could be up and running in a few hours, and I'd have a quick reference API (which is a must for any project).
If you slow down on the coding and take some time to invest on documentation, you will see coding will pickup by itself afterward with more contributors and more efficient development.Just my 0.02$.
-
@ermal:
Since there are so many request for different things i want just to ask a simple question:
Will detailed docs on making a package bring more patches/packages developed by the requesters?
I might throw some time to making a detailed doc on how to create a package for pfSense if i see some interest from people.Absolutely.
-
@ermal:
Since there are so many request for different things i want just to ask a simple question:
Will detailed docs on making a package bring more patches/packages developed by the requesters?
I might throw some time to making a detailed doc on how to create a package for pfSense if i see some interest from people.Absolutely.
Again, ditto. I've been screwing around with some of the inc's and xml's in the packages I've installed, which is cool and all, but the package system is slightly arcane, and I would be far more likely to actually create a package if there were some kind of package docs than currently…turns out, the current situation is likely enough since I'm going to create a package, but that's beside the point. :)
-
Doc(s) on how to build packages would be awesome. I am REALLY wanting to build the bits for installing Dansguardian on pfsense.
-
SpamAssassin
PGP encryption
keystroke encryption
bot/mailware/trojan/scanner
keyloger protection
-
I would love to see a cacti package, it shouldn't be that hard to do.. it's just that I don't have any unix/freebsd knowledge.
The current RDD graphs can only be seen after logging in, I would love to place some graphs on our intranet page for our users to see. Cacti should allow us to do this and also provide more graphing options.
-
Radius server, not radius protocol, radius server ;D
-
ntop, again :)
-
adzapper
-
Maybe we should start a new thread and ask which packages people would like to run on pfSense in appliance mode. Since we have the ability to run pfsense with one NIC and no NAT there may be more interesting requests.
Here is the link in case someone would like to read about the variety of appliance uses for pfsense.
http://www.pfsense.org/index.php?option=com_content&task=view&id=71&Itemid=81
Wireless Access Point
VPN Appliance
Sniffer Appliance
DHCP Server Appliance
DNS Server Appliance
Voice over IP (VoIP) Appliance
With the nice package manager and active user base I bet there are more good ideas out there. I have read in other threads some people mention file sharing. That was discarded by some saying its a firewall you don't want to run samba on it.
Now it seems pfsense is an appliance also.
-
Appliance ideas:
Database Server (with replication)
Web Server
Streaming Music Server
Streaming Video Server
Email Server
Dev Server (options for CVS, SVN, GIT, wiki)
Mirror Client and Server
Session Border Controller -
Some of these Appliance ideas are incorporated into FreeNAS, a related fork of m0n0wall.
I still haven't found the webserver solution I've been looking for. I want an embedded OS to run a webserver, with the /www/doc/ directory on a USB stick (diskless system). FreeNAS will do this just fine, but doesn't have per-directory authentication.
-
Here we go…
Postfix + Davecot POP server + procmail + blockmail.pl + spam assassin + clamav or other antivirus.
A complete client / server mail.
Connect to a mail server, recieve e-mails, scan for virus, use procmail + blockmail to police what is coming from (copy or not to another e-mail local account) and store in server.
In Lan , users can push the e-mail stored in server.
For send e-mail, listed users that can send and a option to copy to other mail what is sended, scan for virus, block attachments, add to e-mail body the message warning about audit.
I can help with commands or manually configure. A gui for that inside pfsense, would be very very good. -
How about Nagios? Im looking forward to have it on my pfsense box.
-
First, I would think it would be best to get the core elements 100% stable. Then get add-on packages like Squid Proxy, SquidGuard, IDS… working as stable as possible.
I would definitely like to help out schools that can't afford a lot for technology on pfSense But problems with SquidGuard puts a serious damper on that. See Google SafeSearch bug in the forum. Simple problems liek this can seriously limit utilization of pfSense.
I have two schools right now that need something like pfSense. I have to corporate donated hardware, just can't get the software that works.
Charlie
-
1 - Peerguardian style package. Something to block out those bad ip's ;) Needs to have peerguardian style auto update blocklists. To me this is a big priority as there is not much for 64 bit windows support for this style of program. Having this feature at the router makes the most sense anyways.
2 - email. it actually would be nice to have an email appliance with webmail. I'm looking at clarkconnect, but only for the email functionality, as the rest is defiantly lacking compared to pfsense.
It's hard to really ask for much more.
-
I have not read thru all 14 pages of the wishlist so I'm not sure if this has been suggested or not.
One of the unique features that is available in Windows SBS servers is Remote Web Workspace (RWW). That feature is not available with any other version of windows or as standalone because it replaces the functionality of a terminal server to some extent. And Terminal Server CALs bring MS a lot of that green stuff.
For those that do not know what RWW is, please do a google search. A video or two of it in action is on the net. Also this: http://www.sbsfaq.com/Lists/FAQs/Attachments/135/Remote%20Web%20Workplace%20-%20Part%201.pdf is a good article on how RWW works behind the scenes.
Now back to the idea of a package: the way I see it, all the functionality that is needs to make an RWW alike package (I'll call it RDP Portal) is already available in pfSense.
Here is how I think the package should work:
The package:
1. Maintains a list of all machines on the private side (interfaces and network ranges configurable/selectable) that can be RDP-ied to. This list can either be manually generated, imported, or generated by doing a scan of the network(s) for machines that listen on TCP:3389 (port selectable in config.) Use DNS to resolve the names (that was understood, why did I even mention it.)
2. Presents a web page on the public side (again interface and IP selectable) that acts as the portal for the RDP Proxy. Once the users log in (authentication based on Kerberos or Radius), they are presented with a list of machines they can RDP into. Some form of access control list can probably be introduced through LDAP or other means here to restrict which machines the user get to see in that list. Also a TCPPing can probably be done to only list machines that are active. May have to be a background scheduled TCPPing so that the network is not jammed by these when the list need to be displayed to the portal client.
3. When a user selects a machine to connect to, a port forwarding rule is created on the fly that maps a dynamic high port (would be nice if a usable port range can be defined and a port from it is randomly selected) on the selected IP on the WAN side, mapping it to port 3389 of the target machine. At the same time a firewall rule is created between the IP that the client contacted the portal with and the RDP machine he chose to connect to. This is where this solution would differ from the MS RDP Proxy they implement in SBS. They proxy the connections and we will be doing this using port forwarding.
4. The RDP portal web page then redirect the user to a page with the ActiveX embedded RDP client to open an RDP connection for the client to the desired machine.
5. Does some sort of states monitoring to see when the connection ends or dies at which point both the port forwarding rule and the access rule can be removed (possibly with a delay since I think the RDP client does try to reestablish the session if for some reason it is lost.)
That is pretty much all I can think of to include in a package like that. I'm sure others can probably add some nifty features to it.
Now there may be security related ramifications of such a package because it would essentially be a scripted mechanism with root access.
I may have some time starting third week of February to possibly start developing a package like this. But I'm not going to be able to do it on my own. Will need help. Probably lots of it.
Thanks,
Shahid