libsodium WAS working fine but now I managed to break it and can't find how to unbreak it.
Amazon AWS Ubuntu Xenial, libsodium18 installed, php-sodium from Ondrej Sury PPA installed but instead of working I now get:
Undefined constant 'Sodium\CRYPTO_SECRETBOX_NONCEBYTES'
The annoying thing is it's fine in Zesty but there's no stable AWS Zesty image still. I'm sure I've just forgotten some simple thing but it's just ceased working.
Found it.
PHP sodium function names have changed so instead of calling \Sodium\crypto_secretbox_open() you now have to call sodium_crypto_secretbox_open()
I seriously hope this post helps someone avoid the grief I've had in the last 24 hours wondering what I'd *^&%'d up - it might well be the only thing on the internet actually pointing this change out that Google finds...
The revised function names and constants are all listed at https://paragonie.com/book/pecl-libsodium/read/01-quick-start.md
The project description explains the reason behind these changes: https://github.com/jedisct1/libsodium-php
There is also a polyfill that provides the old interface: https://github.com/mollie/polyfill-libsodium
However, new libsodium APIs are not available using this polyfill.
I can't maintain both versions, sorry. I wish we could have kept using the original, namespaced version.
Related
i have a problem with some old TYPO3 stuff, i tried to make a old TYPO3 Website run on my Ubuntu system.
And sorry if somethings are not clear to understand for me, i am new in CMS's and i am forced to change some stuff on a old page.
Problems are:
1.
Backend seems working, half. If i enable the ext. TemplaVoila my be Page module shows me a white page.
On TV disable,
Page module, seems working but it gives me some strange error messages inside the content fields.
if i try to look at the front-end it gives me this exception:
1: PHP Runtime Deprecation Notice: Non-static method tx_ttnews_div::getSubCategories() should not be called statically,
assuming $this from incompatible context in
/var/www/projectfolder/projectfolder-typo3/typo3conf/ext/tt_news/pi/class.tx_ttnews.php
line 3740
Just apart from this, i read about a removed php feature in update 5.6 i was using currently.
Things i checked already:
-Correct PHP -v
-Database import correct
-LocalConf correct (took from live server and changed for my localhost)
-Checked install-tool and rm -rf * inside typo3temp folder
Thanks for you help
Your PHP version combined with the versions of TYPO3 and extensions seems to be incompatible. You either need to use a different PHP version or upgrade TYPO3 and/or the extensions being used. FYI, the method being called is from a very old extension so although you don't say which version you're using, I assume your TYPO3 version is very old (either 6.x or even 4.x versions).
The normal recommendation would be to upgrade TYPO3 and any extensions. The less recommended alternative would be to use a different PHP version. But please be aware that remaining on older TYPO3 versions means your site may not be patched for security issues and may not be compatible with modern browsers.
I need the php_monetdb.dll for php 5.4. I've found that by building the monetDB with the HAVE_PHP=1 option on windows will create the dll, but the build procedure fails at numerous points. I am using the monetdb source from sourceforge which is a little outdated one. The newer version has problems in the .msc files itself so proceeding to the build itself is a pain. The older version that I am trying on is atleast passing the nmake step but failing on the nmake install step. The reasons vary from component to component. One states that the devenv /build does not exist. For this I copied the vcexpress and renamed it to devenv. I am not sure if this is right but when I run it from the command prompt it seems to work ok with a few warning alerts shown. During other make installs, the header files seem to be missing. Could anyone please help me with this. Also please let me know if there is any other alternative for this approach of getting php_monetdb.dll.
P.S: I am using windows 7, MSVC 10 express, PHP 5.4.4
For the build questions, see http://bugs.monetdb.org/show_bug.cgi?id=3121
For php_monetdb.dll, see
http://sourceforge.net/mailarchive/forum.php?thread_name=20120717145132.GU49719%40cwi.nl&forum_name=monetdb-developers
http://sourceforge.net/mailarchive/forum.php?thread_name=500581D5.8030808%40acm.org&forum_name=monetdb-developers
I have an inconsistency, and I could not align their versions properly, so I just wanted to remove the library version. Can I do this? Is the header version for PHP while the library is from my distro? Can I upgrade PHP's library version? If so, how? I am using PHP 5.4.4
For example,
Is the header version for PHP while the library is from my distro?
It means it was compiled against the 1.0.1 headers, but is now dynamically linking against 0.9.8. So you are using an older version than what was used when PHP was compiled.
Many libraries store the version in the header files. So when a program uses the library, it can do something like int HEADER_FOO_VERSION = LIBRARY_VERSION, which embeds that version number into the program (e.g., php). Now when that program runs, it links dynamically against the library, which may be a different one than was on the host system.
That library may have a function call, say int get_library_version(). So the program (PHP) can check if HEADER_FOO_VERSION == get_library_version(). If it's different, then there could be a compatibility issue. (Of course, it doesn't have to be assign to a local variable... I'm just trying to drive home the point that the header version number can be compiled into php, and remains constant no matter which version of the library is being used at run time.)
Whether or not it is a problem depends on if the two versions are compatible.
Usually if the library is > than the header, you are okay. It's definitely more likely to be a problem if the library is older than the version it was linked against. Of course, this is because it's impossible to know what changes future versions may have.
So in your case, I would try to update your system's SSL libraries via apt-get, yum, etc, to match the version PHP is expecting.
To check which version php is using on Linux:
$ ldd `which php` | grep ssl
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0
Note that which php is just a short-cut to find the full path. You can hard code any executable you'd like to check: ldd /usr/sbin/httpd.
I dont know the answer myself, but when searched on google some nice resources explaining the same.....
What's the difference between a header file and a library?
The version of the files are the one mentioned in the phpinfo used to create a library.
Hope it helps, there are lot of resource available if searched on google.
Still will like to hear from someone in great details about the question
The header version is the functionality version, whereas the library version is the code version.
The header defines the interface - it tells you what functions are within the library. If a header gets updated, then you need to check to make sure all the functions are the same, and see if any are added or subtracted.
But if a library gets updated, and not the header, it means all the function calls are the same, but some of the code may be changed (eg, bug fixes).
In your example, PHP is seeing functionality for OpenSSL 1.0.1, but the actual version of the source code that OpenSSL is loading is 0.9.8o
This is commonly seen on updated versions of openssl. What happens is the newer versions for the libraries are stored in different folder. The original folder located at /usr/bin/openssl would need a symbolic link to the new folder /usr/local/bin/openssl. That would get both to be the same version or just show OpenSSL Version _(Whatever)
Normally there is no concern for this, since it still works the way it is intended. This is seen a lot on shared servers.
EDIT:
The information in this post is generic and can be different if you are running
CentOS, RedHat, Ubuntu, or another Linux/BSD version. Check documentation or man
pages for the best information
If you do update your OpenSSL, some versions of *nix Require for you to rebuild PHP and Apache for it to update
If you are rebuilding PHP from source, I have found another possible reason for a mismatch. It's so simple yet if you are not familiar with building from source on Linux, not knowing it can cost you a lot of time.
The answer is here: https://serverfault.com/a/567705/305059 - unfortunately I cannot up-vote it over the not-so-useful answer, so if you have the reputation there, please do.
You need to run "make clean" before "make" in order for it to rebuild all binaries. Strangely, without this step I was getting an updated library version, but the old header version - so I think it must have rebuilt something, but not everything. My rebuild involved linking to a version of curl in another location (built with ssl), which might be the reason behind it.
Anyway, I hope this helps someone. Thank you to #velcrow on serverfault.
I'm trying to figure something out:
I am using Ubuntu server 11.10 virtualized on Win7 (I don't think that matters but more info is better than less) to work on a Drupal 6 website I inherited and need to make significant changes to.
I want to set up a development copy of this Drupal website on my Ubuntu server so I can work without worrying about torching the production website.
I successfully got the production files downloaded and onto my machine, I got the production MySQL database exported and imported into the dev MySQL server, and I set up a symbolic link from the directory /home/myname/thewebsite.com to /var/www/thewebsite.com so I can easily access it.
When I got the website they didn't know the admin password so I dug around online and reset it in the dev db using phpmyadmin and finally log in.
When logging in and poking around the site there are lots of errors, which when googled lead me to believe that PHP 5.3 is causing them and that there are some modules in use that only work with PHP 5.2
After looking around a lot online and on stackoverflow there seems to be no easy way to install PHP 5.2 on Ubuntu Server 11.10. With no packages for 5.2 available through apt-get or aptitude what should/can I do?
1) Install 5.2 from source - how do I get it to interface with MySQL and Apache2? Also, I've never installed anything significant from source. Is there a walkthrough?
2) Replace the repositories with old ones? Will this work on 11.10? The newest instructions I found were for 10.04
3) Use already built PHP 5.2 packages for Ubuntu? Couldn't find these
4) Pay someone who knows more to do it for me? (Just kidding, this isn't really an option...)
Cheers and thanks for your help!
PHP dropped support for 5.2 in August 2011; operating system providers such as Ubuntu will not supply a version that is out of support, so you absolutely won't get an official copy of PHP 5.2 on the current version of Ubuntu (or any other OS).
If you're running an older version of Ubuntu (eg 10.04), you might be able to do it; it would still be a downgrade, because PHP 5.3 has been the default version for quite a long time now.
If you're on a newer version of Ubuntu, ie 11.10 as you state, it is going to be a problem for you.
The Drupal developers dropped the ball badly on this one. I guess it was because Drupal 7 tool so long to finish; they were expecting D7 to be out much sooner, and so they never bothered fixing up D6 to work with PHP5.3. As it turned out, this was a big mistake, because in fact D7 still wasn't officially released when PHP dropped support for 5.2.
But even so, they should have fixed it, because they're still officially supporting Drupal 6, so they need it to work with the current version of PHP. This is definitely Drupal's problem, not PHP's, Ubuntu's or yours.
But you still need to deal with it.
I found this question over on AskUbuntu.com, which gives an answer applicable to 11.04. It isn't quite 11.10 you were asking for, but it it a lot more recent than the best you'd found, so it might be helpful.
Alternatively, you could research exactly what it is about Drupal6 and your specific modules that doesn't work in PHP5.3. The language differences between 5.2 and 5.3 that can break things are not big, so I would expect any code changes required to be fairly small. You might find you can fix the code yourself. And maybe even submit the changes to the community -- Drupal is open source, after all.
Another tack you could take is to consider whether this saga represents an opportunity for you to move the site to Drupal 7?
This may or may not be feasible, depending on the modules you're using, etc, but if it is possible, it will solve the problem, because D7 is of course fully compatible with PHP5.3.
And just to cheer you up, I'll close by mentioning that PHP are on the verge of releasing PHP 5.4. Hopefully the Drupal devs will be more on the ball this time.
I have to find out the earliest PHP4 version my code will run under (I already know it runs on PHP5 and on PHP 4.4.9 (the last PHP4 version -- included in MAMP).
Are there code inspection tools that will do this? Do I need to install each PHP version and see what happens :-)
There is a PEAR package in the bartlett.laurent-laville.org channel for this: PHP_CompatInfo
Find out the minimum version and the
extensions required for a piece of
code to run
Examples could be found here.
Note: The original PEAR package is for PHP4 only, and is no longer maintained.
Before you manually download and install various versions of PHP, try to download the XAMPP versions, that have the old php binaries packaged:
Download links on oldapps.com
I use (unit) tests for this purpose.
for v in $versions; do
php$v -f tests.php
done
I don't think there is a tool for that.
I guess you don't have to install all PHP version, try major releases, like 4.1, 4.2, 4.3, etc
To my mind minor releases don't have language syntax changes or anything major, usually it's bug fixes