Oracle Linux Manager file owner issues — oracle-tech

    Forum Stats

  • 3,708,758 Users
  • 2,241,121 Discussions
  • 7,840,594 Comments

Discussions

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Oracle Linux Manager file owner issues

andreas.dijkmanandreas.dijkman Posts: 40 Blue Ribbon
edited January 18 in Oracle Linux

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

  • JustinWiedJustinWied Posts: 3 Red Ribbon

    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.

  • andreas.dijkmanandreas.dijkman Posts: 40 Blue Ribbon

    Thanks, didn't know about the 2.11-part being scheduled for Q1 2021. That helps!

  • Avi Miller-OracleAvi Miller-Oracle Senior Manager, Oracle Linux and Virtualization Product Management Melbourne, AustraliaPosts: 4,656 Employee

    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.

    andreas.dijkman
  • JustinWiedJustinWied Posts: 3 Red Ribbon

    Oh, good to know! I will checkout Oracle Linux Manager 2.10. Thank you.

  • Avi Miller-OracleAvi Miller-Oracle Senior Manager, Oracle Linux and Virtualization Product Management Melbourne, AustraliaPosts: 4,656 Employee
  • User576183-OracleUser576183-Oracle Posts: 79 Employee
    edited January 18

    @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 the apache 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.

    [[email protected] ~]# groups apache 
    apache : apache 
    [[email protected] ~]# groups tomcat 
    tomcat : tomcat apache 
    


    spacewalk-backend-2.10.28-1.0.6.el7 performs a chmod on the configured modules directory during a yum upgrade, as follows:

    sw_mount_root=$(awk '/kickstart_mount_point/ { print $3 }' %{rhnconf}/rhn.conf)                                                                                                                                                            
    if [ -n "$sw_mount_root" ]; then                                                                                                                                                                                                           
      chmod -R g+w "$sw_mount_root/rhn/modules"                                                                                                                                                                                              
    fi   
    


    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 to apache, and chmod 770 for all files/directories under the modules directory. This in combination with the default OL7 group config, and spacewalk-backend upgrade process should allow all tools to operate on the modules tree.

    I have attached two files. They show identical spacecmd clone and spacewalk-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.


  • andreas.dijkmanandreas.dijkman Posts: 40 Blue Ribbon

    @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.

Sign In or Register to comment.