- 3,708,758 Users
- 2,241,121 Discussions
- 7,840,594 Comments
Forum Stats
Discussions
Categories
- 22 Industry Applications
- 3.2K Intelligent Advisor
- 4 Insurance
- 745 On-Premises Infrastructure
- 251 Analytics Software
- 21 Application Development Software
- 1.7K Cloud Platform
- 700.4K Database Software
- 17.4K Enterprise Manager
- 4 Hardware
- 106 Infrastructure Software
- 70 Integration
- 45 Security Software
Oracle Linux Manager file owner issues

So I have installed the Oracle Linux Manager 2.10 onto my existing (Oracle) Spacewalk 2.10.
I can clone and use spacewalk-manage-channel-lifecycle for OL7-channels without a problem. However using that tool on OL8-channels with modular data has been frustrating for a day.
The tool reposync is creating the modules-directory (in /var/satellite/rhn/modules) and runs a chown 770 on the created directories and chmod apache:apache on them.
[[email protected] modules]# pwd /var/satellite/rhn/modules drwxrwx---. 2 apache apache 91 Dec 30 14:50 dc-monthly-epel8-modular-oraclelinux8-x86_64 drwxrwx---. 2 apache apache 26 Nov 5 16:06 dc-monthly-oraclelinux8-x86_64-appstream drwxrwx---. 2 apache apache 4096 Dec 30 12:39 dc-monthly-oraclelinux8-x86_64-codeready-builder drwxrwx---. 2 apache apache 91 Dec 30 14:42 epel8-modular-oraclelinux8-x86_64 drwxrwx---. 2 apache apache 4096 Nov 30 10:45 oraclelinux8-x86_64-appstream drwxrwx---. 2 apache apache 91 Dec 30 12:38 oraclelinux8-x86_64-codeready-builder
If I run the tool spacewalk-manage-channel-lifecycle on channels with modular data, it is talking to the API in Tomcat, that is running as user tomcat.
spacewalk-manage-channel-lifecycle --clear-channel --promote <rest of options>
So the cloning (with clear) is failing in the background because the modular data copy is failing. In the code, tomcat is trying to do a chmod 770 on those modules-directories but it can't because ownership is not tomcat but apache and ownership can only be changed by the owner of the files.
If I do a chown tomcat:apache on /var/satellite/rhn/modules/*, the process works, because the user doing the chown-ing is owner of the files. This also works because I put the user tomcat in the apache-group. The process also works if I run tomcat as user root, but I don't want to do that.
Does anybody have any tips? Maybe running tomcat as user apache, but then al sorts of other things may go wrong because the use apache can't write to directories that are owned by tomcat.
Comments
I'm currently using Oracle Spacewalk 2.7, eager to upgrade to a version that supports Oracle Linux 8. I've heard that 2.11 will better support appstreams / modules and is expected to be released Q1 2021.
Hopefully this issue that you've come across will be addressed in 2.11.
Thanks, didn't know about the 2.11-part being scheduled for Q1 2021. That helps!
Oracle Linux Manager 2.10 is the release with as much support for modularity as we're currently planning. It replaced the previously planned Spacewalk 2.11 release.
@andreas.dijkman are you an Oracle Linux customer who can open an SR? If so, it would be great if you could do that. I'll also point the engineering team at this thread so they're aware.
Oh, good to know! I will checkout Oracle Linux Manager 2.10. Thank you.
You're welcome. :)
@andreas.dijkman, thanks for your detailed post.
I cannot reproduce this issue on either a clean install of Oracle Linux Manager 2.10, or an Oracle Spacewalk 2.10 system upgraded to Oracle Linux Manager 2.10.
You state:
If I do a chown tomcat:apache on /var/satellite/rhn/modules/*, the
process works, because the user doing the chown-ing is owner of the
files. This also works because I put the user tomcat in the
apache-group.
The
tomcat
user is already in theapache
group in a standard OL7 and OLM 2.10 install. If you're having to manually alter groups, I'd suggest that there is something non-standard in your OL7 setup.spacewalk-backend-2.10.28-1.0.6.el7
performs achmod
on the configured modules directory during ayum upgrade
, as follows:In the past I believe you've been patching your own fork of our GitHub repo. Are you upgrading using only our official packages, or have you applied code you've patched yourself?
In testing I observe both
spacewalk-repo-sync
and the XMLRPC API running in Tomcat setting the group toapache,
andchmod 770
for all files/directories under the modules directory. This in combination with the default OL7 group config, andspacewalk-backend
upgrade process should allow all tools to operate on the modules tree.I have attached two files. They show identical
spacecmd clone
andspacewalk-manage-channel-lifecycle
commands on an upgraded system and a cleanly installed system, respectively.I believe that OLM is functioning correctly in both upgrade and clean install scenarios. As Avi suggests, I'd request you log an SR if you need further assistance.
@User576183-Oracle yes, I've used my own patched version but now I only use the OLM-RPM's. I've even did a reinstall of the RPM's from the OLM-channel, so I don't have any custom patched versions running.
I checked the permissions again and setting them like yours now results in the same behavior as your installation. I think in some of the upgrade steps I had something didn't go as planned on my system. In some state I had the clone-channel-module-data as owner apache:apache, not sure how that happened. My migration path was RHEL SW 2.10 -> Oracle SW 2.10 -> OLM 2.10. I think somewhere in between I hit this problem that in RHEL 2.10 the files didn’t have the proper owner and I changed the ownership to fix that. After upgrading to Oracle SW 2.10 and later OLM 2.10 this problem occurred.
Many thanks for looking into this.