Does anyone know, from which version is in Network Manager available option disabled? I am writing puppet module and to write it propperly I have to specify in which version to use ignore and where to use disabled for ipv6.method property inside keyfile.
I found out that EL7 uses ignore and EL8 uses disabled, but I want to write it for many distros, so I need to specify exact version of NetworkManager.
I found it out. To use ipv6.method=disable, the version of NM must be 1.20 and greater.
Related
We are currently using RHEL 8, but intend to move to RHEL 9. The rpm I create currently Requires ncompress, which is no longer available so my package can no longer be installed on a new RHEL 9 host. To resolve this, can I simply have "Requires: compress, uncompress" and let the package figure out where to get them, is there a downside to this? Is there a way to find what the new package should be (I cannot find documentation for a recommended replacement), or is it better to modify my code to use gzip and gunzip and require that package instead? Is there another option that I am not thinking of to get around this issue?
Thanks.
We ended up changing the our compress/uncompress functionality to use gzip/gunzip and could remove the requirement.
I want to have unattended-upgrades installed on my server and I want to edit the default config. I like to receive mail to confirm an upgrade, I know where to change it in config files.
andschwa/unattended_upgrades doc clearly says that puppetlabs/apt can manage unattended upgrades but there is nothing said in the doc.
Can I have some help to configure unattended-upgrades with puppetlabs official apt module ?
I know that there is several modules to manage unattended-upgrades but I want to be sure that it is not possible with puppetlabs/apt before adding another module like puppet/unattended_upgrades as it is said that it is not available for debian 8.
Thanks
andschwa/unattended_upgrades doc clearly says that puppetlabs/apt can manage unattended upgrades but there is nothing said in the doc.
The functionality was removed from puppetlabs-apt in version 2.0.0 (now 4.0.0), and moved into puppet-unattended_upgrades (the Vox Pupuli module).
I want to be sure that it is not possible with puppetlabs/apt before adding another module like puppet/unattended_upgrades as it is said that it is not available for debian 8.
This looks like a mistake in the metadata only that's been fixed in git since the latest release (2.2.0). The code to handle Debian 8 (Jessie) appears identical in the released version to git, so I'd say you can and should use this module to manage unattended-upgrades.
I'm trying to overwrite a jsp from a LR 7 module, in the bnd.bnd file of the fragment module you have to provide the version:
Fragment-Host: com.liferay.announcements.web;bundle-version="1.0.6"
Let's assume this version is only supported for example in CE GA3, so what will happen if on CE GA2 or GA4 the bundle-version needs to be different to make it work or should i create multiple fragments modules projects in order to support different original module version ?
If I understand you correctly, you're asking if you can override more than one version of a bundle with the same fragment? I don't think you can, but even if you could, you shouldn't.
From the Liferay Docs on overriding a module's JSPs:
Supplying a specific host module version is important. If that version
of the module isn’t present, your fragment won’t attach itself to a
host, and that’s a good thing. A new version of the host module might
have changed its JSPs, so if your now-incompatible version of the JSP
is applied to the host module, you’ll break the functionality of the
host. It’s better to detach your fragment and leave it lonely in the
OSGi runtime than it is to break the functionality of an entire
application.
I am generating rpm-A that has program P-A.1.1, and two libs L-A.1.1 and L-B.1.1.
L-A.1.1 changes some APIs it used to expose compared to it's previous version - L-A.1.0
Say the machine had another program P-B.1.0 that uses L-A.1.0.
Will installing rpm-A break program P-B.1.0?
Will L-A.1.1 co-exist with L-A.1.0?
A
If you are upgrading the package that had previously provided P-A.1.0 and the new version of the package no longer provides that version of the library and only provides the P-A.1.1 version of the library then RPM will not allow that upgrade to occur without being forced because it would break P-B.1.0.
You have a number of options to handle this sort of thing.
You can provide both libraries in the same package.
You can change the package name (e.g. gnupg.gnupg2 or iptables/iptables-ipv6 though those are both for slightly different reasons than this).
You can use library symbol versioning to have your library expose both APIs at the same time (I believe).
I've built a Name Service Switch Module for Red Hat Linux.
Using strace, I've determined that the OS looks for the library in various directories, but only for files with the extension .so.2 (e.g. libnss_xxx.so.2, where xxx is the service name)
Why doesn't it look for .so or .so.1 libraries? Is there any guarantee that it won't stop looking for .so.2 libraries and start looking for .so.3 libraries in future?
EDIT: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, says that the 2 is 'a version number that is incremented whenever the interface changes'.
So I guess that:
The version of NSS requires version 2 of the libraries.
An OS update with an updated NSS might require a different version number.
Can someone confirm whether that is true?
You're assumption is generally true with a minor edit:
The version of NSS requires a version of the libraries with interface version 2.
An OS update with an updated NSS might require a different version number.
The version of an interface does not necessarily need to change with the version of the library, i.e. a newer version of the library might still provide the same interface.
There are two types of so files: shared libraries (loaded and scanned for symbols at compile time, loaded again and linked at program startup time) and modules (loaded and linked at run time). The idea of shared libraries is that your program requires a certain version of the library. This version is determined at compile time. Once the program is compiled, it should continue to work even if a new (incompatible) version of the library is installed. This means that the new version must be a different file, so old programs can still use the old library while newer (or more recently compiled) programs use the newer version.
To properly use this system, your program must somehow make sure that the library version it needs will continue to be installed. This is one of the tasks of a distribution's packaging system. The package containing your program must have a dependency on the required version of the library package.
However, you seem to be talking about modules. Things are different there. They do not carry such a version, because ld.so (which takes care of loading shared libraries) isn't the one loading them. Your program should be bundled with those modules, so the module versions are always compatible with the program using them. This works for most programs.
But it doesn't work if your program allows third party modules. So they can come up with their own versioning system. This seems to be what nss has done (I'm not familiar with it, though). This means that they have defined a protocol version (currently 2), which specifies what a module should look like: which symbols need to be defined, what arguments do functions expect, these sort of things. If you create a module following version 2 of the protocol, you should name your module .so.2 (because that's their way of checking your supported version). If they create a new incompatible protocol 3, they will start looking for .so.3. Your module will no longer be found, and that's a good thing, because it will also not support the new protocol.