Check a package that has XMLRPC sync, it will help. IIRC, you can call php functions as well shell cmds. The only thing I know for sure is that any message/output from remote box generates alert erros on first box.

You would need a lot more than just make. You need the entire development toolset and compilers. As already suggested a firewall is no place to do things like this.

many many thanks…. you are great.... thank you very much.. finally i've got the iso and memstick images after built. I've been searching since last week and i thought there might be compilation / building errors., but no they are in /tmp/pfSense as you said. Thank you again...

Oh well.  I had a great weekend drinking beer… and now I'm back online so I can get working on my package again but I can't be the only person who would want to do this.  I see lots of views, but no replies. If anyone has any ideas even I'm game to try them out since it seemed to me that it should be very possible.  If there is something pfSense really needs from the internet I should be able to mirror it locally just like the package root but I don't know what that would be...

@cmb: Expired is a different state than disabled. Neither state can be used. An expired account isn't set to disabled by design and isn't a bug, whether expired accounts should also be set to disabled is another question. I'm not sure. There isn't a problem with the way things are currently done, and some things log differently for expired vs. disabled which some people would consider a feature. Okey, understand now. Thanks.

@jimp: If you install two versions of the same package, they probably will overwrite each others' files. Whichever one you installed last will be the files that are in place. It's highly unlikely that you really need two versions of perl installed. Just install the new one, 5.14.x, and things should use it. Wouldn't hurt to run "perl-after-ugprade" so it can hunt down libraries in the old perl dirs and move them to the new ones Hi. perl was example. Clearly, I'm trying to build an iso with squid + guard + freeradius based pfSense 2.0.1. pfSense's php-mysql extension installs mysql-client-5.5.25 and freeradius-2.1.12_1 depending on mysql-client-5.1.63. ( I use your package repo. ) So mysql-client-5.1.63 fails. I use the way that you install bsdinstaller to pfSense. But today I've noticed, freeradius-2.1.12_1 originally builded without mysql, openldap etc. I've used it and solved the problem in this way. It works but I don't know how sensible :)

RELENG_2_0 is currently 2.0.2-RC3, not 2.1. If you want 2.0.1 exactly you need to build from the tag RELENG_2_0_1 You're better off on 2.0.2 though.

Is this for USB or Serial UPS ??

@jimp: Yes, there are even patches in there for 9, and it "mostly" works but there were many problems… random freezes, lots of things in the OS that we needed to code around (check redmine, there's a whole tree of 'em), formats of various things changed that need to be adjusted for. So it might function, if you're lucky, but don't expect a miracle. If it actually worked properly, we'd be using it. Thanks for the heads up… I tried to register on redmine and had no luck. I still would be interested on running it buggy or not at least it would generate logs that can be used for patches

Assuming that the names are fairly unique between the ports in question, just put them all into a single tag. If a port doesn't use that specific WITH or WITHOUT option then it will just be ignored. The only place that doesn't work is when you have one port that needs WITH_FOO and another that needs WITHOUT_FOO. I'm not sure how common that is. Expanding the tag might be an option if that doesn't work, it still has to obey the xml rules (build_port_path is a listtag, if you make an array of some other name it will break parsing on existing installs). So while what you proposed wouldn't work, it might work like so: <build_port_path><port_dir>/usr/ports/category/coolthingy</port_dir> <options>WITH_AWESOMENESS=true WITHOUT_BUGS=true</options></build_port_path> <build_port_path><port_dir>/usr/ports/category/dep</port_dir> <options>WITHOUT_STUFF=true</options></build_port_path> That said - PBIs are supposed to detect and self-contain all dependencies. So if the port actually properly handles dependencies, it will get them all (yay) so try just using the main PBI first and see if that works. If not, then worry about the deps. FreeBSD .tbz packages were broken here and there with this, which is why we ended up with the current zany process of adding in all these extra binaries by hand that should really be automatic.

It wasn't delayed; the CARP interfaces were brought up once, and that happened before the packages. There could definitely be something I'm overlooking so I certainly welcome more scrutiny. Thanks! :)

For my purposes, I will manually set my skew values by not syncing VIPs automatically, however the 255 value is a legitimate bug, and I've updated the bug report and made a pull request in github with the fix: https://github.com/bsdperimeter/pfsense/pull/127 http://redmine.pfsense.org/issues/2012

Thank you Jim, I have gotten past the part where it normally errors out. It is building kernels now and it should finish normally from here.

I'm not sure but it can be about php.ini file.