In order to patch RedHat 7 machines to version 7.9, I've created an RPM repository with RPMs extracted from a DVD.iso file of the patch (example source guide), and updated said machines using yum.
The patch has succeeded with many of the machines (RHEL 7.7 only), but the rest (7.0, 7.2 and some 7.7 as well) have failed the with the following error:
Error: requested datatype filelists not available
I've also tried to gradualize the process and patch the 7.0 and 7.2 ones to 7.7 first by the same process, but yielded the same result. I've made sure I got each and every file in the Packages folder.
It is rather puzzling for me that some succeed and some fail, especially those with the same version. But I'm assuming they were created differently as I don't have the information to say otherwise. So my best direction would be to go by the error.
In this github post, lr1980 says:
https://blog.packagecloud.io/eng/2015/07/20/yum-repository-internals/
this means the "filelists.xml.gz" is missing on repo => it's a packager.io problem
Indeed, browsing my repository's repodata folder reveals only other.xml.gz and primary.xml.gz files, which are also the only files pointed to in the repomd.xml.
I've tried uploading the filelists.xml.gz file from the dvd.iso and reindexing, but it gets removed (admittedly am not familiar with this area of knowledge.. at all). What does "it's a packager.io problem" mean?
How can I force the repo to have such a file, assuming that's what I need? Or what can I do to solve this issue otherwise?
Many thanks
Dears,
I am managing a pool of servers running under RHEL 7.6, I created a local repository of RHEL packages to be able to udpated the other servers by limiting the internet access to the server hosting the local repository.
I used the reposync command to populate my repository but I am downloading a huge number of rpms packages!
I would like to reduce the set of packages to download to the ones already deployed on all the severs, I can do the list using the rpm command, (~750 packages).
I read that there is an includepkgs directive to be used with the reposync command.
How is it working, what is the required format?
I know it is possible to use the yumdownloader command to update the local repository, how is it possible to populate the repository for the first time ?
Any help advice would be appreciated
Regards
Fdv
It seems that the best option is to limit to the last version of the packages by using the option :
-n, --newest-only Download only newest packages per-repo
Apache Tomcat 7.0, CentOS 5.8 i386
A web application needs a specific environment variable XY to be present in its context.
This variable is set in /etc/profile as a result of a computation (i.e. not a static value) and it is also used by other native applications running on the same system (hence it has to be the environment variable approach).
Tomcat is started with a general script using a dedicated tomcat user and sudo.
The first problem of passing XY through sudo is solved (thanks to stackoverflow) with the explicit definition within /etc/sudoers:
Defaults env_keep ="XY"
It means that the environment variable XY is preserved by sudo which is not the default case.
Now the environment variable XY is visible in the tomcat process. This can be verified with ps and /proc/tomcat-PID/environ or an explicit echo $XY in */your_tomcat/bin/startup.sh* (which is called by the init.d script using sudo). But seeing XY in the tomcat process does not mean the web app can see it. The web app dumps its environment to the log file with help of
LOGGER.debug("Environment: " + System.getenv());
the astonishing result for me was: no XY at all, although tomcat had it!
After reading the context documentation of tomcat 7.0 (be careful to distinguish between 7.0 and older versions of tomcat) I added the following entry to */your_tomcat/conf/context.xml*:
<Context>
...
<Environment name="XY" value="INIT_VALUE" type="java.lang.String"/>
...
</Context>
Now the output of System.getenv() really contains my XY environment variable BUT it has the correct value from /etc/profile not the value INIT_VALUE I specified in context.xml. With other words my /etc/profile does overwrite the INIT_VALUE, which is what I needed but not what I expected as there is no word about this in the documentation.
Did I find un-docmented behaviour that might be removed in later versions of tomcat or is this the way to go?
So in the end I am happy having a working solution but I am not very confident that this is a recommended and proper way of passing-through environment variables.
Any comments would be highly appreciated.
Tomcat Environment entries are different from system environment variables. Environment Entries specified by <Environment> markup are JNDI, accessible using InitialContext.lookup under java:/comp/env, while System.getEnv() is about system environment variables (of the tomcat process itself).
We have updated our Plone sites to version 4.1
We would like to install also the Pageturner PDF viewer in the site to give our users more functionality on medical articles which are published as PDFs.
We added in the buildout file two parts:
eggs =
.......
wc.pageturner
zcml =
.......
wc.pageturner
We also installed on our Ubntu server machine the swftools with the command:
$ sudo apt-get install swftools
Running buildout is going well without any errors.
After starting the zinstance the Plone sites are not available within the browser.
If you are interested we could write some functional documentation to add on plone.org with the product.
What can I do? where is the error? Am I missing something?
It seems a common problem relative to the way permissions are handled in Plone 4.1.
Just add the following:
<include package="Products.CMFCore" file="permissions.zcml"
xmlns:zcml="http://namespaces.zope.org/zcml"
zcml:condition="have plone-41"
/>
in every configure.zcml file where CMF permissions (cmf.ManagePortal, cmf.ModifyPortalContent, etc.) are mentioned.
php -v gives this
PHP Warning: PHP Startup: memcache: Unable to initialize module
Module compiled with module API=20060613
PHP compiled with module API=20090626
These options need to match in Unknown on line 0
PHP Warning: PHP Startup: memcache: Unable to initialize module
Module compiled with module API=20060613
PHP compiled with module API=20090626
These options need to match in Unknown on line 0
bogus test name tests/
ps. i've upgraded from php 5.2 to 5.3. before this everything worked okay.
When you update the version of PHP (especially when going from version X.Y to version X.Z), you must update the PHP extensions as well.
This is because PHP extensions are developped in C, and are "close" to the internals of PHP -- which means that, if the APIs of those internals change, the extension must be re-compiled, to use the new versions.
And, between PHP 5.2 and PHP 5.3, for what I remember, there have been some modifications in the internal data-structures used by the PHP engine -- which means extensions must be re-compiled, in order to match that new version of those data-structures.
How to update your PHP extensions will depend on which system you are using.
If you are on windows, you can find the .dll for some extensions here : http://downloads.php.net/pierre/
For more informations about the different versions, you can take a look at what's said on the left-sidebar of windows.php.net.
If you are on Linux, you must either :
Check what your distribution provides
Or use the pecl command, to re-download the sources of the extensions in question, and re-compile them.
just
pecl uninstall module_name
then
pecl install module_name
Your problem is within the php5-dev package. I guess you went from php5.2 on an older linux version to php5.3. I did the same thing, and when I managed to install php 5.3 there was a conflict with php5-dev. For some reason it doesn't get upgraded to the new version. Dunno why is that and I don't care, however this makes your extension compiled with the older API version, while php ofc is with the newer api version. What I did to solve this problem was:
I removed php5-dev with
sudo apt-get remove php5-dev, then I ran sudo apt-get autoremove to get rid of the leftovers that were giving me the trouble, and after that I just installed php5-dev again.
sudo apt-get install php5-dev.
Once that was done, I removed my memcache with sudo pecl uninstall memcache and installed it again sudo pecl install memcache. Now both the module and the php had the same api version so I knew right away that I had the issue solved :)
Hope it helps.
It's possible that the modules are installed, but your PHP.ini still points to an old directory.
Check the contents of /usr/lib/php/extensions. In mine, there were two directories: no-debug-non-zts-20060613 and no-debug-non-zts-20060613. Around line 428 of your php.ini, change:
extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"
to
extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20090626"
Then restart apache. This should resolve the issue.
I struggled with this issue for a long time and found out that when you run configure, just pass it the path to the correct php-config tool.
In my case, it was
./configure --with-php-config=/usr/local/zend/bin/php-config
... If you're unsure, run a locate php-config on your machine and find the right one amongst the different versions installed.
Hope this helps somebody in the future.
PS. My default php-config was set to 20090926 which is PHP 5.3. The one I manually entered as a param for ./configure was for PHP 5.4 (2010...)
I had this part enabled in my php.ini
extension=php_memcache.dll
[Memcache]
memcache.allow_failover = 1
memcache.max_failover_attempts=20
memcache.chunk_size =8192
memcache.default_port = 11211
After commenting these lines composer was installed in my windows 10
I had a similar issue after upgrading from PHP 5.5 to PHP 5.6. The phpize and php-config libraries being used to compile the phalcon extension were still the ones from PHP 5.5. I had to run the command below:
sudo apt-get install php5.6-dev
There will be a long stacktrace, the key information I saw was this:
update-alternatives: using /usr/bin/php-config5.6 to provide /usr/bin/php-config (php-config) in auto mode
update-alternatives: using /usr/bin/phpize5.6 to provide /usr/bin/phpize (phpize) in auto mode
I hope this helps someone.
Before you phpize, make sure to update your path ($PS1) to point to the new PHP! phpize uses your environment, and if you still have vestiges of your old PHP in your path or other parts of the environment, things will get hairy!
I'd the same error even after recompiling the modules.
But I solved it you just have to specify the absolute path of your phpize.
Here is the one that works with php 5.5. Download xampp 1.8.3 from here and download memcache dll from here
In my case in php.ini
[CLDbg]
extension=php_cl_dbg_5_3_VC9.dll
clport=6000
I removed Codelobster which support different PHP version, so need to update to:
[CLDbg]
;extension=php_cl_dbg_5_3_VC9.dll
;clport=6000
This problem has just happened to me and has been solved simply by increasing
memory_limit from 32 M to 64 M
You can adjust the value on the file where php.ini exists
locate php.ini
then choose the right file and search for memory_limit and after modifying it
you must reboot the apache
/etc/init.d/httpd restart
All the best.
In my case, I used lnmp to install php with version 5.4.45. But maybe because I installed php5-dev after lnmp (which I guess is not necessary if you installed lnmp), my phpize and php-config both point to older version tools than php.
I solved this by change the soft link of /etc/alternatives/phpize and /etc/alternatives/php-config to /usr/local/php/bin/phpize and /usr/local/php/bin/php-config.
Hopes this is helpful.
What worked for me was simply to do the following:
open the php.ini file.
Under the DYNAMIC EXTENSIONS heading, comment out the following line as
;extension=php_java.dll
Restarted Apache and all was fine