New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHP Versions/Other Bugs (2.0.1) #212

Open
deklar opened this Issue May 9, 2015 · 11 comments

Comments

Projects
None yet
2 participants
@deklar

deklar commented May 9, 2015

Version 2.0.1
Module Installed: only fmDNS
Authentication: built-in
OS: FreeBSD 10.1-p8
PHP: 5.6.7 (build details available if needed)
Apache 2.4.12
MySQL 5.6.23
Hardware: 128GB Memory, 10 x E5-2660, SSD for OS & SQL

There are a number of bugs I'd like to bring up. I can create a new issue for each one if required.

Firstly I need to say that I'm in no way putting down fmDNS. It's fantastic and simply the best thing out there today. I have not seen any reports of what I'm going to mention, so this is a FYI.

I'm not sure if any testing has been done on PHP 5.6.7 or not, I ran into several issues that I believe are in direct relation to the PHP version changes.

  1. I cannot (in the web interface) add a user. No PHP errors, no Apache errors, simply the message "Could not add the user to the database." I found this error in the source and could not explain it without digging further.

  2. There is a change in the way that PHP handles arrays after a certain version. When changing the password for an account, below the gauge (which shows weak/strong/etc), instead of filling in the rest of the element, it instead displays "hint [array]" - I got around this by simply removing that line of code in password_reset.php (the on line 95).

  3. (perhaps a missing feature) Outside of direct SQL, there seems no way to clear the log file (this may have been brought up before).

  4. The enabled named checks work - however, I had to disable them due to unnecessary checks. For example: When you have 2000 domains added with over 60,000 records, adding a single domain requires a check - this takes 20-30 minutes alone. If there is a way to only check the new addition that would be handy.

(minor notes below, may not be broken)

  1. Zone templates are counted as the total count of zones and records, I'm not sure if this was done purposely or if it should be corrected. Doesn't bother me all that much but it's nice to have a real count of actual zones.

  2. I had to bypass PHP-FPM for facileManager as they did not play nice together. After several requests/posts PHP-FPM would loop, FPM reported "exited with code 0 after 0.015971 seconds from start" - this would go on forever consuming all system resources until manually stopped. Not using PHP-FPM works perfectly fine however. We use PHP-FPM on no fewer than six servers with hundreds of websites and applications without an issue - this is the first time I've ever seen this happen.

Thanks

@deklar

This comment has been minimized.

deklar commented May 9, 2015

Forgot one:
Client installation (when talking to the server for the first time), using dns.php install - says the BIND version is not supported (which it is).. "BIND 9.9.7 (Extended Support Version)" is what is reported, so I suspect that sed(1) is not parsing it correctly. Got around this by modifying the source (forced it to accept).

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented May 11, 2015

Thanks for the submissions. We can leave these in one ticket for now and I have not tested fM with PHP 5.6 yet so I'll have to build a test environment to reproduce these errors.

WillyXJ pushed a commit that referenced this issue May 13, 2015

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented May 13, 2015

Still looking into these and how to best approach them, but here are some simple updates/requests:

  1. Fixed in 2.0.2.
  2. I'm assuming this client is also running FreeBSD 10.x. Could you please get me to the full path of named and then the full output of named -v?
@deklar

This comment has been minimized.

deklar commented May 13, 2015

Same OS.

"BIND 9.9.7 (Extended Support Version)"

/usr/local/sbin/named

Client finds named just fine. I think the issue is somewhere along the lines of line 276 in functions.php for fmDNS (client side).

WillyXJ added a commit that referenced this issue May 13, 2015

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented May 13, 2015

While I wasn't able to reproduce the client version compare with a FreeBSD 10.1, BIND 9.9.7, and PHP 5.6.8 test environment, I see how it could fail. A fix has been submitted for the upcoming bug fix release and you're welcome to confirm the changes before the release by manually applying the fix (abc321c).

@deklar

This comment has been minimized.

deklar commented May 13, 2015

Negative, but I can help ... just found the issue.

The version_compare will work fine with text after the actual version.

The client of course prunes off BIND with sed(1), leaving just: 9.9.7 (Extended Support Version)

So, "9.9.7 (Extended Support Version)" is sent to the server. The function validateDaemonVersion was never being hit. The change to the clients functions.php from buildconf to buildconf.php probably was still needed (haven't tested this part).

The fix: Remove the prefixing "/" character before buildconf.php in your patch.

I think this was throwing off the index path (or what have you, I'm not a PHP person) in fm-init.php on the server side.

Once that prefixed slash was gone, clients can be installed.

Side note: Since FreeBSD 10, named is no longer shipped with it. You won't find the named startup script in /etc/rc.d anymore. If it's installed from the ports (I suspect most people do this) you'll want:

functions.php for fmDNS on the client side, this line:

'FreeBSD' => '/etc/rc.d/named start',

Should be replaced with:

'FreeBSD' => '/usr/local/etc/rc.d/named start',

Thanks.

WillyXJ pushed a commit that referenced this issue May 26, 2015

WillyXJ pushed a commit that referenced this issue May 26, 2015

WillyXJ pushed a commit that referenced this issue May 26, 2015

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented May 26, 2015

Update:

  1. Still working this issue
  2. Fixed in 2.0.2
  3. Feature request - No update
  4. Feature request - No update
  5. Fixed in 2.0.2 (including rc script location)

WillyXJ pushed a commit that referenced this issue May 27, 2015

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented May 28, 2015

  1. I've been able to reproduce the issue by not having php-ldap installed. Can you please confirm this is the same for your environment (the user add window does not contain an option for "Authentication Method")?

screen shot 2015-05-27 at 7 15 49 pm

versus

screen shot 2015-05-27 at 7 16 28 pm

@deklar

This comment has been minimized.

deklar commented May 28, 2015

Correct, there is no method for the authentication method under the add user window.

WillyXJ pushed a commit that referenced this issue May 28, 2015

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented May 28, 2015

  1. Fixed in 2.0.2

Still looking at the feature requests.

@WillyXJ WillyXJ modified the milestone: 2.x release May 28, 2015

WillyXJ pushed a commit that referenced this issue May 28, 2015

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Jul 9, 2015

\3. Coded checked in for v2.1 release
\4. Took a look at this request and there's no easy way of determining which changes were made that require a check.
\6. No update

@WillyXJ WillyXJ modified the milestones: 2.x bug fixes, 2.x release Dec 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment