Confusion on package installation
I've installed pfSense 1.2-RELEASE on a vmware test/learning platform.
My confusion is, System->Packages page does not include all the packages which can be found either in http://www.pfsense.com/pfSense/pkg_tester.php or http://www.pfsense.com/packages/pkg_config.xml or http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/tools/packages/ . Can anyone please explain why that is and point me a direction on installing them?
I'm no expert on this, but I'd wager that the <required_version>tag has something to do with what you will see in the list of packages from http://www.pfsense.com/packages/pkg_config.xml. As well, if you look carefully, you'll notice that there are a bunch of packages listed outside of the <packages></packages>tags (starting with <package>upnp</package>).
The package <name>ifdepd</name> says that it's <required_version>is 2.0. Therefore, that won't show up in the list of packages as the most recent version of pfsense is 1.2.
That seems reasonable.
However, as I remember from my past experience, for example we could setup oracle db on lets say an RH based (non-RHEL) linux system, we change the /etc/redhat-release file to show oracle that we are using an RHEL version, we could install it. Actually I'm not an expert on BSD systems, if this is possible and if pfSense is actually backwards-compatible or lets just say it is "safe" to do it, how can we fake pfSense to install them?
Or for simplicity's sake, when are the developers are planning to release 2.0?
Or for simplicity's sake, when are the developers are planning to release 2.0?
The release part.
Follow the blog. A term you quickly should learn dealing with pfSense is "When it's ready" this post says it well imo.
I'm sure the developers have very good reason not to offer an easy way of downloading and bootstrapping 1.3 at the moment. If it was made publicly available, some people will expect at least a modicum of support if it doesn't work in their setup, will report bugs that the developers may be aware of and are looking to fix, and there might be disruptive changes waiting to be committed that end users will not find easy to handle.
The pfSense team will be wanting to let people see their work as soon as possible - but it has to be ready for public viewing.
The package part.
Package marked with a different number will never be available unless someone finish them (you can see the spot as the dev's package playground). If there is a package there you'll like to work on you can download what's already made and put it on your own package development server. When it's finish make a post in package forum and the pfSense team will be happy to make it available for you and others to use from pfSense package tree.
Links to get started with packages.
http://devwiki.pfsense.org http://forum.pfsense.org/index.php/board,15.0.html http://diskatel.narod.ru/pfSense/alt_pkg.htm
Hope it clears up a thing or too ( as I'm a none team member it's my own 2 cent :) )
Thanks Perry, this clarified a lot.
Hmm.. Maybe I'll flip a coin and start with one.
I wrote the quote in Perry's post, based in no small part on my experience as a developer elsewhere (but not in this project).
Though I didn't make it clear, the mention about downloading and bootstrapping was thinking of the developer ISO in the context of giving early access to those who are conversant with the internals of pfSense. When you first run the developer ISO after installation, a bootstrap process grabs the latest version of the configured FreeBSD and pfSense CVS branches (or HEAD in the pfSense case; you can't use FreeBSD HEAD nor should you want to) and builds a normal ISO.
Whilst you can check out pfSense 1.3, you'll find it almost impossible to build as I don't think there's a publicly available pfSense developer ISO based on FreeBSD 7.0. Upgrading the FreeBSD version in a developer installation is very much non-trivial.
I am sure we will see snapshots and, later on, beta builds of 1.3 - but the code needs to be ready for those builds to be released. Giving early access when it isn't ready for public viewing causes the problems mentioned in my quote. Neither pfSense nor FreeBSD works on a timed release schedule - in a similar vein, there is currently no timescale for FreeBSD 7.1.
As someone who is very familiar with FreeBSD, though not as familiar with the pfSense internals, I thought I'd try to explain some background that will hopefully help silvermage and others in a similar position.
pfSense 1.2.1 is on its way, which is based on FreeBSD 6.3 rather than the 6.2 of pfSense 1.2-RELEASE. The pfSense team have stated that they hope to release 1.2.1 by the end of May 2008, which is the end of life date of FreeBSD 6.2-RELEASE (and the point at which there's no longer any FreeBSD security team support for it).
There are a great deal of improvements in FreeBSD 6.3 - including better hardware support together with various enhancements and bug fixes that were suitable for backporting from the active development in the HEAD of FreeBSD CVS. FreeBSD refers to such backports as MFC - Merge From Current (FreeBSD CVS HEAD is referred to as FreeBSD CURRENT).
Because FreeBSD 6.3-RELEASE was released so long after 6.2-RELEASE, the 6.3 FreeBSD packages are much more up to date than the 6.2 ones. In fact, the FreeBSD 6.3-RELEASE packages are the same versions as in 7.0-RELEASE because the release cycles of the two OS versions were aligned from a ports/packages point of view. (There were a handful of cases where there were security flaws found in packages between the two OS release dates, so a later version might just have shipped in 7.0-RELEASE in that case). This should help pfSense package developers, as work done on pfSense 1.2.1 should hopefully be easy to port to the FreeBSD 7 based pfSense 1.3.
You talked about different Linux distributions (or 'flavours'). There's no such concept with the BSDs - each is a kernel and userland, unlike Linux where Linux is technically only the kernel and it's up to each distribution to come up with a userland. Each approach has strengths and weaknesses - I prefer the FreeBSD approach, but I can see how there are advantages in being able to have an OS distribution that's packaged to suit your intended application.
Of course, there is code sharing between the BSDs and even from beyond the BSDs when licences are compatible. OpenBSD's OpenSSH, in its portable guise, is used in almost every free *NIX operating system, incluidng the other BSDs. OpenSolaris's ZFS has been ported to FreeBSD - though it's still an experimental feature in FreeBSD 7.0.
There are also derivative distributions - from FreeBSD there's the FreeSBIE Live CD, m0n0wall and pfSense amongst others.
There's usually no trickery needed to install software on FreeBSD. If a FreeBSD port is compatible with a particular major OS version, a binary package will be produced for that version. The port itself, in conjunction with the ports framework, deals with the differences between the OS versions.
If the source material for a port is only available as a binary for a particular major OS version, it is usually possible to use that binary on a later major OS version using the compatibility features of the OS and the compatibility libraries, so a package is still possible - if so, this is transparent to the user. The port maintainers and ports committers do all this work for the end users - though FreeBSD PRs (problem reports) with feature requests, bug reports and especially patches are always welcome for any issue you have with a FreeBSD port or package.
Some Linux binaries can be used on FreeBSD via FreeBSD's Linux emulation. There are some examples amongst the ports and packages of this - usually linux appears in the name of the port or package.
As is often said on these forums, FreeBSD is not Linux. Linux shell scripters can get caught out on FreeBSD because bash is not the default shell, /bin/sh is not bash, and bash is not installed unless you install the bash port/package or install bash from source. Similarly, the default make program on FreeBSD is BSD make - if you need GNU make (gmake on FreeBSD), you need to install the gmake port/package or install from source.
If you wish to do any pfSense development, it may pay to familiarise yourself with FreeBSD, its documentation and ports/packages system. A FreeBSD port is simply the recipe to create a binary package - though installing from ports often allows you to tune the port to your requirements.
I've yet to get into pfSense package development, though I'm going to explore the possibility of an apcupsd package. apcupsd has better support for SNMP managed UPSes than nut - my server rack has such a UPS.
I'm grateful for Perry's links - I knew about the devwiki, but the last one is new to me. I wonder if the right way to develop this is to experiment on the version of FreeBSD i386 corresponding to the pfSense version you're developing for, check your work at the shell of a pfSense developer ISO, then start to build the UI and other components required for a pfSense package. That's only a thought from me, however - it's not based on any experience.