Quagga installation error (chown /)

  • After installing the package the whole pfsense installation gets unusable. There's a bug that the script does a system wide chown -R quagga:quagga /

    It looks like the variable $quagga_config_base is empty/inaccessible during the installation.

    Basically every service who does security checks on file ownership (liked raccoon) stops working…

    The installation script should be fixed. My guess is that when loading quagga_ospfd.inc script the variable isn't correctly set global and therefore not in scope when calling the quagga_ospfd_install_conf()

    It would be nice if someone could fix this.

    edit: please move this thread into the package section. Thanks

  • This only happens if you've already a config in your config.xml or you're restoring your pfsense using a backup.xml.

    If you've a clean installation and install the package then everythingis alright cause there's no config that can be created without the initial configuration.

    It happens only during installation or reinstalling of the quagga package

  • Rebel Alliance Developer Netgate

    That's interesting because it is set, and is declared global, and worked on my test setups.

    Are all of the other places in the rc script that reference the variable blank when you looked?

  • Rebel Alliance Developer Netgate

    Though that does sound familiar, I found another spot when I had to move away from a global here:


    Guess I'll rework this one the same way (and bgpd since I made the same change there)

  • Rebel Alliance Developer Netgate

    For now I removed the / after the variable on the chown line so if it's blank it'll just be invalid syntax rather than doing too much.

  • Cool, when I get time I'll try to find out the cause. I've some things in mins what could cause this error.

    I've also some ideas about raw config, cause I need some things that are not possible to configure via the webgui.

    This would include quagga/zebra static routes (which are different to kernel routes) and route filtering. Until now I used openvpn/tap + quagga on a multisite setup and I'm now trying to replace the central VPN concentrator with pfsense and was running into some issues.

    I also now sure if I want separate config zebra+ospfd or using the unified config Quagga.conf as single config for all quagga services.

  • Yes the problem with chown matches exactly with the bug/git commit. I've the feeling that a different scope is including the quagga_ospfd.inc. Later in the installation process a different function/scope calls the quagga_ospfd_install_conf() function but the config_base variable isn't available in the scope and therefore not available in the install_conf() function resulting in bad chown call.

    I have a few suggestion that would elimate this problem:

    a) the ugly

    just set the variable global right at the beginning of the .inc file (calling global inside the function only applies to this function). This will make the variable anywhere in the the whole php namespace.

    b) the okay

    You could use a CONSTANT to define the config base path and all other package related variables (like uid, etc). The constant would be available globally without having to "global" a variable first to get access to it. The downside would be that the constant can't be changed during runtime, but as this is a config variable I don't see a need for it.


    c) the nice

    Use a class with (static) attributes. You could also use this for other package related informations like uid, gid, name, etc. Instead of class attributes you could also use class constants.

    class pkg_quagga_ospf {
            static $config_base = "path/to/config/";
            static $uid = "quagga";
            static $gid = "quagga";

    A complete redesign of how packages are working if every packages would have a class (the php5.3 package thingy is too new to me tbh). The class could include attributes and pkg related functions, like input checks, etc … I don't know if there's any guide on how packages must look like, but it would cleanup the .inc files.

    P.S. I saw similar problems with variables in other package install files. For example openbgpd: They use chown as well but only on a single file. I bet they would have the same issue when generating a config during the pkg install process.

  • Rebel Alliance Developer Netgate

    yeah, the constant way is probably best for now, I still need to run a few experiments and see what works and what doesn't.

    Using classes and such is good, but would be too big of a design change to do at the moment.

  • Rebel Alliance Developer Netgate

    Committed a fix using constants that works for me.

    Not terribly pretty the way I did it, but since you can't embed a constant into a string I had to take sort of a hybrid approach.

  • of course you can.
    $var = CONSTNAME . "/";

    I theory, the other variables like $pkg_uid shouldn't work either … I'll try to setup my own repo and test it out an a virtualbox. Lets if I get a test/dev environment running.

  • Okay .. As I expected … the whole variables/install process is bugged. I don't know how many other 3rd party packages have this problem but here's what I found out

    1. I changed the quagga_ospfd.inc to include the following debug code
    $quagga_config_base = '/var/etc/quagga';
    $pkg_login	= "quagga";
    $pkg_uid	= "101";
    $pkg_group	= "quagga";
    $pkg_gid	= "101";
    $pkg_gecos	= "Quagga route daemon pseudo user";
    $pkg_homedir	= "/var/etc/quagga";
    $pkg_shell	= "/usr/sbin/nologin";
    // helper function to log a var_dump
    function s_var_dump($x)
    	$return = ob_get_contents();
    	return $return;
    /* ... */
    function quagga_ospfd_install_conf() {
    	global $config, $g, $input_errors, $pkg_login, $pkg_uid, $pkg_group, $pkg_gid, $pkg_gecos, $pkg_homedir, $pkg_shell, $quagga_config_base;
    		'quagga_config_base'	=> $quagga_config_base,
    		'pkg_login'	=> $pkg_login, 
    		'pkg_uid'	=> $pkg_uid, 
    		'pkg_group'	=> $pkg_group, 
    		'pkg_gid'	=> $pkg_gid, 
    		'pkg_gecos'	=> $pkg_gecos, 
    		'pkg_homedir'	=> $pkg_homedir, 
    		'pkg_shell'	=> $pkg_shell
    1. I install the package via the webgui. I can reproduce the same error when pressing reinstall.

    from system.log

    Jun 15 19:18:59 pfSense php: /pkg_mgr_install.php: Array (     [quagga_config_base] =>      [pkg_login] =>      [pkg_uid] =>      [pkg_group] =>      [pkg_gid] =>      [pkg_gecos] =>      [pkg_homedir] =>      [pkg_shell] =>  )
    1. Here is the log output when I save a configuration via the webgui. That's the logout you normally would expect
    Jun 15 19:20:03 pfSense php: /pkg_edit.php: array(8) {   ["quagga_config_base"]=>   string(15) "/var/etc/quagga"   ["pkg_login"]=>   string(6) "quagga"   ["pkg_uid"]=>   string(3) "101"   ["pkg_group"]=>   string(6) "quagga"   ["pkg_gid"]=>   string(3) "101"   ["pkg_gecos"]=>   string(31) "Quagga route daemon pseudo user"   ["pkg_homedir"]=>   string(15) "/var/etc/quagga"   ["pkg_shell"]=>   string(17) "/usr/sbin/nologin" }

    Variables defined inside the package.inc aren't available when pkg_mgr_install.php is calling the <custom_php_resync_config_command>option.

    I'll look into the installation process to see if I can find anything to tweak but I've to understand and find the code first.

    otherwise all packages should be checked if they contain variables defined inside the .inc file. When I was playing around with the quagga package (I know it's flagged as BETA) any my whole filesystem got changed ownership to quagga:quagga various parts of my pfSense stopped working. for example, racoon refused working cause the psk.txt had a wrong ownership. In the worst case (when the whole fs got changed) you end up with a defect pfsense installation and you're only option is to reinstall the firewall completly.</custom_php_resync_config_command>

  • Rebel Alliance Developer Netgate

    That's not embedding :)

    By embedding I mean

    $str = "blah{$otherstr}/blah";

    (which yes you can concatenate, or use printf but it's not as convenient)

    or this which has no workaround AFAIK:

    $str = <<<eof<br>something {$otherstr} somethingelse

  • Atm I can't find any workaround this variable/scope issue during the package installation process apart from creating constants for all variables. I've the feeling that a multiple require_once called in different places (install_package_xml, sync_package, uninstall_package) can cause this issues.

    The way with using a constant is the only practical way atm without doing a bigger redesign. Oh btw. you can move all the pkg_* variables into the install_conf() functions. they aren't used anywhere else apart for the config installation.

    I attached a patch against the current git version. It also added support for raw config of zebra.conf and ospfd.conf. You need to be able to edit both files, cause quagga static routes and everything routing/kernel related are handed by zebra and only ospf stuff is handed by the ospfd. There's a feature called integrated config where you only have one config (like if you would use vtysh on the cli) but quagga team recommends having seperate configs for each daemon (zebra, ospf, bgp, isis)