Thanks Jim. Helpful, exactly what I needed :)

Yep. But I don't really see how could I include my stuff into it. Could anybody point me into the right direction please? I need to sync config files (proprietary format, not xml) and restart services affected.

Have a look on github for pfsense forks https://github.com/Podilarius/

It's unintentional (and not related to the other thread), we're aware of it being down and it should be back up soon. It's not the only thing impacted at the moment it's just the most visible from the outside.

@efk: Can someone explain the proper/clean way to update the config.xml file in pfsense? I see some code meant to handle the XML, and i see write_config(), but I'm having a hard time putting it all together. A brief tour of the componants and a quick example would help me out immensely. Thanks in advance! From what I understand: conf_mount_rw(); For making nanobsd read/write global $config; For manipulating the config $config['installedpackages']['packagename]['a']['b']['something'] = "something"; Array elements write_config(); To write the config conf_mount_ro(); For moving nanobsd back to read only Example Code function create_vnstati_image() { conf_mount_rw(); global $config; $iface = $_POST['vnstat_interface']; $ifaces_final = convert_friendly_interface_to_real_interface_name($iface); $config['installedpackages']['vnstat2']['config'][0]['vnstat_interface'] = $ifaces_final; exec("/usr/local/bin/vnstati -i ". $ifaces_final ." -vs -o /tmp/newpicture1.png"); exec("/usr/local/bin/vnstati -i ". $ifaces_final ." -m -o /tmp/newpicture2.png"); exec("/usr/local/bin/vnstati -i ". $ifaces_final ." -d -o /tmp/newpicture3.png"); exec("/usr/local/bin/vnstati -i ". $ifaces_final ." -t -o /tmp/newpicture4.png"); write_config(); conf_mount_ro(); } Matching Example XML <installedpackages><vnstat2><config><monthrotate>1</monthrotate> <vnstat_interface>em0</vnstat_interface> <vnstat_phpfrontend>on</vnstat_phpfrontend> <vnstat_interface2>em1</vnstat_interface2></config></vnstat2></installedpackages> I think we multiple tags that are in the same xml hierarchical level you would then use an index element in the array $config['installedpackages']['packagename]['testpackage']['config'][0]['something'] = "something in config 0"; $config['installedpackages']['packagename]['testpackage']['config'][1]['something'] = "something in config 1"; $config['installedpackages']['packagename]['testpackage']['config'][2]['something'] = "something in config 2"; <installedpackages><testpackage><config><something>something in config 0</something></config> <config><something>something in config 1</something></config> <config><something>something in config 2</something></config></testpackage></installedpackages>

You have to use the MEMSTICK-SERIAL image on a usb memstick and boot from it, then install pfsense on mSATA or SD if you want.

Hello, Thanks very much for answering my question! –jason

I figured out I need mwexec_bg and I was killing the processes killbyname("socat"); in the wrong location so it was also not showing up. root    socat      45837 3  stream /var/run/check_reload_status root    socat      45837 9  tcp4  *:19006              *:* root    socat      45529 3  stream /var/run/check_reload_status root    socat      45529 9  udp4  *:19005              *:* root    socat      45424 3  stream /var/run/check_reload_status root    socat      45424 9  tcp4  *:19005              *:* root    socat      45258 3  stream /var/run/check_reload_status root    socat      45258 9  udp4  *:19004              *:* root    socat      44829 3  stream /var/run/check_reload_status root    socat      44829 9  tcp4  *:19004              *:* root    socat      44561 3  stream /var/run/check_reload_status root    socat      44561 9  udp4  *:19003              *:* root    socat      44058 3  stream /var/run/check_reload_status root    socat      44058 9  tcp4  *:19003              *:* root    socat      43605 3  stream /var/run/check_reload_status root    socat      43605 9  udp4  *:19002              *:* root    socat      43237 3  stream /var/run/check_reload_status root    socat      43237 9  tcp4  *:19002              *:* root    socat      42753 3  stream /var/run/check_reload_status root    socat      42753 9  tcp4  *:19001              *:* root    socat      42315 3  stream /var/run/check_reload_status root    socat      42315 9  tcp4  *:19000              *:*

@Amirkabir: From /etc/inc/auth.inc: /* root user special handling */ if ($user_uid == 0) { $cmd = "/usr/sbin/pw usermod -q -n root -s /bin/sh -H 0"; if($debug) log_error(sprintf(gettext("Running: %s"), $cmd)); $fd = popen($cmd, "w"); fwrite($fd, $user['password']); pclose($fd); } ive tried but it does not work

@freebee: Received the new PC Engines (Alix) board today. The APU Amd board. Just waiting the pfSense 2.2 build for tests. :). already tested. Seems OK (about the speed of a FW-7541, really) except for some throughput tests over TCP, which suck.  I blame the ethernet driver.

Upstream the question was 'what is the point of ZFS on a firewall? it just complicates things.' That's certainly the case for many sorts of firewalls.  Consider firewalls that do lots of caching of client side http downloads, that run postfix mail exchangers and other 'big storage' packages.  Restoring from an XML backup doesn't preserve the mail queue, doesn't preserve potentially gigabytes of cached downloads.  ZFS snapshots and rollbacks and remote sends can do that. There's an even better reason:  The ability to run pfsense with ZFS on the 'bare metal' with direct access to several hardware nics, while running other 'close to the network' type servers (web, mail, cloud, voip/pbx, etc) in virtual machines running on a 'big iron' style pfsense install.  All those can use zvols maintained by ZFS on the bare metal with all the sys-admin and error catching advantages zfs brings. Currently to use ZFS and pfsense on a 'big iron' system, pfsense has to run in a virtual machine and the network interface card 'plumbing' is a pain.

I have finished my script for the autoremoval of expired users and it seems to work  :) I created the file delete_expired_users.php in /usr/local/bin and set the needed permission (chmod 755) and added a cronjob running once a day, the auth_addon.inc from above is placed in /etc/inc Use at your own risk! #!/usr/local/bin/php -f require_once("auth.inc"); require_once("auth_addon.inc"); // How many users are there? $id = count($config['system']['user']); // We must begin our search for expired users with the last useable ID // Else strange things happen to the config.xml :) $check_id = $id - 1; // Check all found users except ID 0 - it's the admin, no need to check him while ($check_id != 0) { // Get the username $uname = $config['system']['user'][$check_id]['name']; // Get the user's expirydate $uexpirydate = $config['system']['user'][$check_id]['expires']; echo "USER: ".$uname."\n"; echo "EXPIRES: ".$uexpirydate."\n"; // Check if the user is expired - function of auth_addon.inc if ( isAccountExpired($uname) ) {   echo "EXPIRED: YES \n";   // Delete user locally - function of auth.inc   local_user_del($config['system']['user'][$check_id]);   // Delete user in config - function of auth.inc   unset($config['system']['user'][$check_id]);   echo "USER DELETED! \n"; } else {   // User isn't expired or has no expirydate set   echo "EXPIRED: NO \n"; } echo "### \n"; // Next ID $check_id = $check_id - 1; } // Write the new config write_config(); ?>

Cool, thanks for the tip!

@jimp: Those are only better if you trust that ECC hasn't been compromised by the NSA, which seems to still be under debate/scrutiny. Well, if you don't trust the ECC stuff, then you still would want the larger RSA key sizes, since 3072-bit RSA corresponds to AES-128 key strength.  If you do trust the ECC stuff, you can get a performance boost at the larger key-equivalent sizes to 192-bit and 256-bit AES (384-bit and 512-bit ECC), since you'd need 7680-bit and 15360-bit RSA respectively.  The former is slow, but probably tolerable in many applications; the latter is impractically slow.

I want to compile the images.  Which files should be changed?

Thanks Phil; that's helpful to understand.  It then seems like both the touch pfSense-build.conf, and the const char * fixes in check_reload_status need to be made to get the build to work.