The SP3 upgrade instructions say that these files must be checked and updated manually. Unfortunately I have no idea what to look for or what might have to be updated. Should I be able to safely disregard them for now? This server’s only purpose is to run ZCM.
Second question: After the upgrade only the following software repositories are enabled:
The first two make sense as does the fourth, I guess, since that was the installation disc. I find it odd, though, that the SP2-Extension-Store is enabled but the SP3-Extension-Store, while available, is not enabled. Do I need to make any manual changes here, or is it fine as-is?
The SP3 upgrade instructions say that these files must be checked and
updated manually. Unfortunately I have no idea what to look for or what
might have to be updated. Should I be able to safely disregard them for
now? This server’s only purpose is to run ZCM.[/color]
The reason you have .rpmnew files is because when updating the
package(s) which own those files they were found to be newer than in the
package so the newer file became .rpmnew. Similarly the .rpmsave files
are from the same situation except it’s the old files which have been
renamed to .rpmsave.
What you need to do is check the differences between the .rpm[save|new]
files and the correct files. You can use diff for this where you “diff
oldfile newfile” i.e. diff /etc/postfix/main.cf /etc/postfix/main.cf.rpmnew
(I wouldn’t worry about /etc/localtime as that’s a symbolic link to a
timezone file in /usr/share/zoneinfo/)
[color=blue]
Second question: After the upgrade only the following software
repositories are enabled:
The first two make sense as does the fourth, I guess, since that was the
installation disc. I find it odd, though, that the SP2-Extension-Store
is enabled but the SP3-Extension-Store, while available, is not enabled.
Do I need to make any manual changes here, or is it fine as-is?[/color]
I would add the SP3-Extension-Store and remove the two SP2-related repos.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
[QUOTE=smflood;22486]On 08/07/2014 16:24, jcw av wrote:
The reason you have .rpmnew files is because when updating the
package(s) which own those files they were found to be newer than in the
package so the newer file became .rpmnew. Similarly the .rpmsave files
are from the same situation except it’s the old files which have been
renamed to .rpmsave.
What you need to do is check the differences between the .rpm[save|new]
files and the correct files. You can use diff for this where you “diff
oldfile newfile” i.e. diff /etc/postfix/main.cf /etc/postfix/main.cf.rpmnew
I would add the SP3-Extension-Store and remove the two SP2-related repos.
Thank you, I wasn’t aware of the diff command. I used it and examined the output, but unfortunately I have no idea whether the changes made were appropriate or not. The good news is that our Samba share, DNS/DHCP (I forgot to mention those server functions), and ZCM all seem to be working. We don’t really use Postfix on the server, and any problems with “catalina”, which I believe is related to Tomcat, would probably manifest themselves in ZCM. Therefore, without becoming an expert in all of these different config files I think my only real option is to assume for now based on the evidence that the files are okay. If you know of any particular issues to watch for in these files please let me know.
With the repository changes I now have enabled only SLES11-SP3-Updates, -Pool, and -Extension-Store.
I have no idea whether the changes made were appropriate or not
initially you talked about “.rpmnew” files… so your system is still running with the old config files. IOW, as things seem to work for you, the old config files still seem to be appropriate and still work with the new software versions.
You may be suffering from insecure settings or that new features are not available, for instance. Being the admin of the system, it usually is a good idea to actually learn what those configs (and their changes) are about, if they are for enables services. But I fully understand that until things actually break, the temptation not to spend serious amounts of time on this is a big one
[QUOTE=jmozdzen;22493]
initially you talked about “.rpmnew” files[/QUOTE]
I should have looked that up - yes, the report includes .rpmsave files, too :[ So for those, the new settings are active, indeed, and might be missing config changes that were applied to the original (pre-update) system. From my experience, you’d notice problems with these rather quickly.
You hit the nail on the head. We’re a small operation, with only two guys taking care of way too many systems. Managing our Linux servers is only a small fraction of my duties, and I just don’t have time to gain the expertise that Linux seems to require. It’s why Linux will probably always be more intimidating to some of us than is another OS that shall remain nameless. It seems to me that if an SP update is going to make changes like this then instead of just listing what files were changed (or proposed to be changed) that rcrpmconfigcheck should provide information about what it did and why.
I have no idea which of the many other OS you’re talking about
Looking at it from a different angle, the picture looks slightly different: Any OS that ships such a variety of software packages faces the same problem: Once you start the “update all!” process, there’s plenty that will change. It’s different for those OS that only come with a very limited base set and you’re buying all sorts of individual add-ons to solve specific problems or needs… the OS update will not change that much and you’ll be installing updates to each add-on separately.
The changes for each configuration are (or should be) described in that package’s documentation - rcrpmconfigcheck is only reporting the results of the automatic update routines that come with each package. And IMO that’s not only sufficient, but the right way to handle it.
The changes for each configuration are (or should be) described in that package’s documentation - rcrpmconfigcheck is only reporting the results of the automatic update routines that come with each package. And IMO that’s not only sufficient, but the right way to handle it.[/QUOTE]
Assuming that I somehow find the time for the recommended post-upgrade package research, where would I go? Unfortunately what rcrpmconfigcheck offers is quite insufficient for a non-expert like myself. It seems to me that it could offer some web links. Ideally that information would include specifics on what package settings the upgrade changed on that system, or it should at least focus on changes generally made when going from the previous patch level to the new. Lacking any of that extremely helpful output now, however, can you please point me in the right direction?
again: rcrpmconfigcheck can only report that some package’s installer has decided to leave the configuration task to the admin of that service - it’s the packages’ postinstall routines that create those “rpmsave” or “rpmnew” files, not rcrpmconfigcheck. Think of “rcrpmcheck” as a “find” command, run to spot all these left-overs of previous update runs.
First thing I check under such circumstances is whether I actually need/run that service at all. If I can disable the service, I need not worry about its configuration file(s) and make sure that the new one is active and the old one is put aside.
Then, if I cannot judge the changes by looking at the files themselves, I look at the manual pages or other documentation of the service. If in question what the service/package actually is, “rpm -qf ” ought to tell you which package “hosts” the config file (not the “rpmsave” or “rpmnew” file, but the actual config file name). If the man page doesn’t help (or doesn’t exist), then “rpm -ql ” may expose some documentation files installed on the local system and “rpm -qi ” sometimes gives a pointer to some project web site.
If you feel that the package installer needs to report more and/or better details on the upgrade process, you need to contact the package maintainer, which usually is someone “upstream” from SUSE for open source packages. Of course, opening a service request with SUSE will make sure you receive appropriate installation/upgrade support, too.
