Tag Info

New answers tagged

0

A supported version of Tomcat7 is available via the add-on entitlement for JBoss. Red Hat has stated that there will not be a Tomcat7 in the RHEL6 base channels. https://access.redhat.com/site/solutions/128503 RHN login is required to view.


2

On RHEL /usr/bin/java is a symlink to /etc/alternatives/java which is managed by alternatives. There is not a single package that provides /usr/bin/java. If you want to look for packages that contain Java, use yum whatprovides '*/java'


1

Is there a mechanism built into rpm or apt that will warn (or prevent) a user from installing a package contains a known security threat? No. Knowing this kind of thing is part of the job of being a professional systems administrator. I don't expect (or want) my tools to spoon-feed me. Nor do I want them to prevent me from doing something destructive ...


1

Normally I have a list of files that I want to verify. So here's a simple bash alias that does more or less what you want: dpkg-verify() { exitcode=0 for file in $*; do pkg=`dpkg -S "$file" | cut -d: -f 1` hashfile="/var/lib/dpkg/info/$pkg.md5sums" if [ -s "$hashfile" ]; then rfile=`echo "$file" | cut -d/ -f 2-` ...


1

The canonical tool for managing RPM packages is rpm. To query the Changelog of an RPM package the command would be: rpm -q --changelog openssl


0

Thanks to @devicenull for leading me down the right path. I got the following to work. I had to hardcode distroverpkg as well as the cachedir and persistdir. Here is my repo file: # cat puppetlabs.repo.el6 # NOTE: This [main] section is required to workaround yum wierdness when we mirror distroverpkg=6 from an el5 host [main] distroverpkg=6 ...


1

I'm guessing the machine you're using also has the puppetlabs repo installed in /etc/yum.repos.d/? If you remove it from there (and flush the yum cache), do you still see this issue? I would suspect you're going to want to give reposync an entirely new yum.conf (via --config), specifying a different cache directory then the normal system one.


1

The answer is not as simple as sticking an RPM with a newer revision in the repo. There are things to be done on the server side and on the client side. Server Side Copy RPM to repo cd /path/to/repo createrepo --update . This will update the repo's database to include the new RPM sudo chmod -R ugo+rX /var/www/html/repo/ This will make the new RPM visible ...


7

This is a Red Hat Software Collection. It's meant to live outside the normal filesystem locations so as to not conflict with original system packages (in this case, the original MySQL 5.1). This means that, yes, you have to perform additional steps to use the software. See the documentation for complete details on how to use Software Collections.


0

After considering this for a while, I think the more correct approach is to use RPM virtual resource "namespaces". E.g.: Provides: resource # 'resource' is available to the whole system Provides: namespace(resource) # 'resource' is specifically available only to "namespace" The RPMs end up looking like this: grunk-libs.rpm Provides: ...



Top 50 recent answers are included