If it's properly declared global before use it may be OK… Or there's the ever-popular "touch a flag file in /tmp/" style. Though if debug_backtrace() shows it being called by the package install code that would be pretty obvious, though I'd have to run some tests to find out how deep that goes. If the info is there it would definitely be the most reliable way. It's not really a bad way to go about it, it just needs some experimentation to derive the required tests/info.

Be aware there will be differences due to the different PHP versions on 2.3 vs 2.2.x. It's OK for basic testing but be careful.

whois is in 2.3. We don't strip as much of stock FreeBSD anymore in 2.3.

Just FYI, fixed in Chrome a couple of days ago. (And meanwhile screwed a whole bunch of other JS: https://code.google.com/p/chromium/issues/detail?id=527930)  ::)

This is used in lots of packages without any problem. Yeah, keep those package accounts outside the reserved range.

Problem is, I want to get the data into an iphone-app… Doing a http-get is piece of cake, doing a SNMP-call, I have no idea how. Also I tried using some sort of snmp-walk software for windows, and it returned hundred, if not thousands of rows from Pfsense, seems to be quite a steep threshold in learning how SNMP works... Now onto the good news : I ugly-hacked it! It was as easy as going into the php-file and uncomment this row: require_once('guiconfig.inc'); That seems to bypass the whole auth-system. No idea what other issues this may cause tho :O Follow-up question: It doesnt seem that the interface bandwidth speeds are reported in any of these outputs? Do I need to do consecutive calls to ifstats.php and calclulate the speeds myself?

Thanks :) Perfect sense, now it's explained! And thus one learns New Things…  ::)

Hmmmm… I submitted a bunch of packages stuff (that wasn't move anywhere) and I wanted some visual hints about the context of some of the changes before doing a PR, so tried to use the GitHub preview for that... The preview didn't work at all, showed the original file all red, the new all green (-> useless). Now it somehow shows like it used to for some smaller stuff... The bigger files, still nothing.

The fsck is a pile of garbage. You can move to https://bugs.freebsd.org/bugzilla/, file a bug and wait a couple of years. Don't expect any fixes here.

I got it  ;D had to create an file called "external-links" in same folder where is the pbi.conf external-links # Files to be Sym-Linked into the default LOCALBASE # One per-line, relative to %%PBI_APPDIR%% and LOCALBASE # Defaults to keeping any existing files in LOCALBASE # Use action binary for binaries that need wrapper functionality # TARGET                LINK IN LOCALBASE      ACTION #etc/rc.d/servfoo      etc/rc.d/servfoo        keep #include/libfoo.h      include/libfoo.h        replace #bin/appfoo            bin/appfoo              binary,nocrash #bin/appfoo2            bin/appfoo-test        binary bin/clamconf            clamconf                binary

IIRC if you add it here, someone will eventually pick it up and translate. https://github.com/pfsense/pfsense/tree/master/usr/local/share/locale/en/LC_MESSAGES (If you want it working locally, you need to regen the .mo files, read gettext docs.)

Yes, it can be a tag. Just something that can be easily found and used as a known comparison point. FreeBSD 10.2-RELEASE is out: https://www.freebsd.org/releases/10.2R/announce.html

Do all the ports just get built with the default options from the ports tree, or is there some way to override them? (miniupnpd will still happily create mappings that steal ports in use by the firewall itself…)

Although the Thread is old. Its also working with PCBSD 10.1.2. @Hobby-Student: Update: EDIT #1: Downloaded this one https://github.com/pcbsd/pcbsd/tree/releng/10.0 and did /src-sh/libsh -> make install /src-sh/pbi-manager -> make install

Yes, what you say is correct. And it is all a bit of a pain in PHP, you have to constantly check isset() is_array()… I have protected all the unset() in /etc/inc/upgrade_config.inc with this pull request: https://github.com/pfsense/pfsense/pull/1773 I guess it was a bit much for the devs to dump into 2.2.4 just days before release. I can't see anything that would go wrong with it - it can only be better - but it does need to have some upgrades from old configs run against it just to confirm all is well.

It was intentionally added. It's useful for a variety of things. Two immediate things were Azure and some testing automation we're doing.

Thanks for the feedback. After the last of our changes on Friday, we had an APU and ALIX running power cycles over and over in a loop while permanent rw mounted on the slowest SD/CF I could find. Each went through 1000 power cycles with no issue. IP PDUs are handy. :) Only certain cards seem to corrupt themselves easily in that circumstance. A SanDisk CF even with SU+J and permanent rw didn't break. The Kingston CF I used for the 1000 cycles never made it more than 2-3 power cycles left rw SU+J. The last part on config writing is being tested right now. The basic case, making a config change and immediately pulling the power, was fine last week. The enclosing directory wasn't being fsynced though, which meant if you did something insane like write_config() in an endless loop called at startup and drop its power right in the middle of that loop, you could be left with a wiped out /cf/conf/backup/ because it overwrote the entire history in 1-2 seconds of the loop and that wasn't fsynced. If you hit the exact right (or wrong) moment, you could end up with a missing config, and no backups to restore. That's about a 1 in 200-300 tries occurrence where you're writing the config in a non-stop loop when power is lost, and probably impossible to encounter in any reasonable real world circumstance. But even that scenario should be fine now. Two systems running in a power cycle loop right now to confirm that. Leaving that running all night.

Yeah they hadn't gotten old enough to be cleared automatically and didn't do so manually until now. They're gone.

@Derelict: I am just hoping that if anything significant happens security-wise we will see an update for 2.1.5.  Until limiters are fixed 2.2 is simply not an option (at least for me in a couple cases.) Highly unlikely. We were hoping 2.2.3 would be the last 2.2.x release even, so we could focus more on 2.3. But 2.2.3 has a couple small issues that need addressing so we'll be putting out a 2.2.4 in the near future. I'm all for releasing more often. In addition to keeping everyone more up-to-date, so long as there are few if any regressions then it's better than letting bugs or security issues sit out there for longer periods of time. Some people also fall into the false trap of thinking a project is inactive if they do not release very often. If you check our repositories you will see we are very active, but when we go for long periods between releases people seem to think the project is dead or suffering, which is not the case.