Oracle Linux Manager file owner issues — oracle-tech

    Forum Stats

  • 3,714,551 Users
  • 2,242,576 Discussions
  • 7,844,931 Comments

Discussions

Howdy, Stranger!

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

Log In Register

Categories

Oracle Linux Manager file owner issues

andreas.dijkman
andreas.dijkman Member Posts: 46 Bronze Badge
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.

· Share on TwitterShare on Facebook

Comments

  • JustinWied
    JustinWied Member Posts: 4 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.

    · Share on TwitterShare on Facebook
  • andreas.dijkman
    andreas.dijkman Member Posts: 46 Bronze Badge

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

    · Share on TwitterShare on Facebook
  • Avi Miller-Oracle
    Avi Miller-Oracle Senior Solution Architect, Oracle Cloud Infrastructure Developer Adoption Melbourne, AustraliaPosts: 4,727 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
    · Share on TwitterShare on Facebook
  • JustinWied
    JustinWied Member Posts: 4 Red Ribbon
    https://community.oracle.com/tech/apps-infra/discussion/comment/16781236#Comment_16781236

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

    · Share on TwitterShare on Facebook
  • Avi Miller-Oracle
    Avi Miller-Oracle Senior Solution Architect, Oracle Cloud Infrastructure Developer Adoption Melbourne, AustraliaPosts: 4,727 Employee
    https://community.oracle.com/tech/apps-infra/discussion/comment/16781238#Comment_16781238

    You're welcome. :)

    · Share on TwitterShare on Facebook
  • Laurence Rochfort-Oracle
    Laurence Rochfort-Oracle Member Posts: 81 Employee
    edited January 18
    https://community.oracle.com/tech/apps-infra/discussion/4479161/oracle-linux-manager

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

    modules_clone_clean_install_system.txt
    modules_clone_upgraded_system.txt


    · Share on TwitterShare on Facebook
  • andreas.dijkman
    andreas.dijkman Member Posts: 46 Bronze Badge

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

    · Share on TwitterShare on Facebook
  • andreas.dijkman
    andreas.dijkman Member Posts: 46 Bronze Badge
    edited February 12

    @User576183-Oracle I need to come back on this. It seems that after a (nightly) reposync the permissions of ALL modules-directories. It seems that if there are updated modules, the modules path get reset to apache:apache.

    Before update:

    [[email protected] modules]# tree -pug .
.
├── [drwxrwx--- tomcat   apache  ]  intern-oraclelinux8-x86_64-appstream
│   ├── [-rwxrwx--- tomcat   apache  ]  af57ef43168bb64ce58f3284ba437ef76487439430172b9d5152198a3532d770-modules.yaml
│   └── [-rw-r--r-- tomcat   tomcat  ]  dee934a2a0933cd2588514ce60315430ce316314fa50027f6cfe32354fb6ea97-modules.yaml
├── [drwxrwx--- tomcat   apache  ]  intern-oraclelinux8-x86_64-codeready-builder
│   └── [-rwxrwx--- tomcat   apache  ]  43eb20cde7cc526c7ed473d2efb6a6fcf96cbbf486f3367f9d70617c04e3a156-modules.yaml
├── [drwxrwx--- tomcat   apache  ]  monthly-oraclelinux8-x86_64-appstream
│   └── [-rwxr-x--- tomcat   apache  ]  af57ef43168bb64ce58f3284ba437ef76487439430172b9d5152198a3532d770-modules.yaml
├── [drwxrwx--- tomcat   apache  ]  monthly-oraclelinux8-x86_64-codeready-builder
│   └── [-rwxr-x--- tomcat   apache  ]  43eb20cde7cc526c7ed473d2efb6a6fcf96cbbf486f3367f9d70617c04e3a156-modules.yaml
├── [drwxrwx--- apache   apache  ]  oraclelinux8-x86_64-appstream
│   ├── [-rwxrwx--- apache   apache  ]  1404b1cbd3c054a3f52c4424650306e295f742f27bfc13b48f632b93ad4b970e-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  1f3327d39041d2283f22ee143b87d776c536f70d55519c5bd2dc3fbbfd66a3c1-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  40a2da9f2ad65612b104dc1ef18fbf370c107e2b2af0775c6a6e726eeca5d5a9-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  98a9a606cd7b554b9eb6b85a4bbd02a647d1036f4c0bd22e46aaf36c50d3f91e-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  af57ef43168bb64ce58f3284ba437ef76487439430172b9d5152198a3532d770-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  d2b877d1546a839e0beb72c8e10d3a28bf07ca8cde66db2cf8618390ad7743f6-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  d4a2fbb56fd0c5b765590a0f540fba67920779c35b6b442b112b4ae5d9766817-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  dee934a2a0933cd2588514ce60315430ce316314fa50027f6cfe32354fb6ea97-modules.yaml
│   └── [-rwxrwx--- apache   apache  ]  f3a59e7979be332f073f460a2df26ec8e5620cc135f8b9a53f7c5e5576eb34fd-modules.yaml
└── [drwxrwx--- apache   apache  ]  oraclelinux8-x86_64-codeready-builder
    ├── [-rwxrwx--- apache   apache  ]  43eb20cde7cc526c7ed473d2efb6a6fcf96cbbf486f3367f9d70617c04e3a156-modules.yaml
    └── [-rwxrwx--- apache   apache  ]  8ecaac2a90785d1ca794050e616958e10297078ca91af9e9474f5e3773950d05-modules.yaml

6 directories, 16 files
[[email protected] modules]# pwd
/var/satellite/rhn/modules

    After update:

    [[email protected] modules]# tree -pug .
.
├── [drwxrwx--- apache   apache  ]  intern-oraclelinux8-x86_64-appstream
│   ├── [-rwxrwx--- apache   apache  ]  af57ef43168bb64ce58f3284ba437ef76487439430172b9d5152198a3532d770-modules.yaml
│   └── [-rwxrwx--- apache   apache  ]  dee934a2a0933cd2588514ce60315430ce316314fa50027f6cfe32354fb6ea97-modules.yaml
├── [drwxrwx--- apache   apache  ]  intern-oraclelinux8-x86_64-codeready-builder
│   └── [-rwxrwx--- apache   apache  ]  43eb20cde7cc526c7ed473d2efb6a6fcf96cbbf486f3367f9d70617c04e3a156-modules.yaml
├── [drwxrwx--- apache   apache  ]  monthly-oraclelinux8-x86_64-appstream
│   ├── [-rwxrwx--- apache   apache  ]  af57ef43168bb64ce58f3284ba437ef76487439430172b9d5152198a3532d770-modules.yaml
│   └── [-rwxrwx--- apache   apache  ]  dee934a2a0933cd2588514ce60315430ce316314fa50027f6cfe32354fb6ea97-modules.yaml
├── [drwxrwx--- apache   apache  ]  monthly-oraclelinux8-x86_64-codeready-builder
│   └── [-rwxrwx--- apache   apache  ]  43eb20cde7cc526c7ed473d2efb6a6fcf96cbbf486f3367f9d70617c04e3a156-modules.yaml
├── [drwxrwx--- apache   apache  ]  oraclelinux8-x86_64-appstream
│   ├── [-rwxrwx--- apache   apache  ]  1404b1cbd3c054a3f52c4424650306e295f742f27bfc13b48f632b93ad4b970e-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  1f3327d39041d2283f22ee143b87d776c536f70d55519c5bd2dc3fbbfd66a3c1-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  40a2da9f2ad65612b104dc1ef18fbf370c107e2b2af0775c6a6e726eeca5d5a9-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  98a9a606cd7b554b9eb6b85a4bbd02a647d1036f4c0bd22e46aaf36c50d3f91e-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  af57ef43168bb64ce58f3284ba437ef76487439430172b9d5152198a3532d770-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  d2b877d1546a839e0beb72c8e10d3a28bf07ca8cde66db2cf8618390ad7743f6-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  d4a2fbb56fd0c5b765590a0f540fba67920779c35b6b442b112b4ae5d9766817-modules.yaml
│   ├── [-rwxrwx--- apache   apache  ]  dee934a2a0933cd2588514ce60315430ce316314fa50027f6cfe32354fb6ea97-modules.yaml
│   └── [-rwxrwx--- apache   apache  ]  f3a59e7979be332f073f460a2df26ec8e5620cc135f8b9a53f7c5e5576eb34fd-modules.yaml
└── [drwxrwx--- apache   apache  ]  oraclelinux8-x86_64-codeready-builder
    ├── [-rwxrwx--- apache   apache  ]  43eb20cde7cc526c7ed473d2efb6a6fcf96cbbf486f3367f9d70617c04e3a156-modules.yaml
    └── [-rwxrwx--- apache   apache  ]  8ecaac2a90785d1ca794050e616958e10297078ca91af9e9474f5e3773950d05-modules.yaml

6 directories, 17 files
[[email protected] modules]# pwd
/var/satellite/rhn/modules

    See fix and analysis in post below.

    · Share on TwitterShare on Facebook
  • andreas.dijkman
    andreas.dijkman Member Posts: 46 Bronze Badge

    Ah, I think I found it. By using the function setPermsPath the owner is reset to apache:apache, if called by the correct owner. As taskomatic is run by user root, the reposync-proces is called by user root. Anyway, if in some way the function setPermsPath is called without the paramater user, it is automatically changed to apache.

    I think the error is introduced in LINUX-8154, where the reposync-function is changed to use setPermsPath without a owner (so it's defaulting back to apache). I need to test this on my test-environment but this doesn't look right.

    In reposync.py, line 584 and further:

    # update permissions
rhn_path = os.path.join(CFG.MOUNT_POINT, 'rhn')
fileutils.createPath(rhn_path) # if the directory exists update ownership only
for root, dirs, files in os.walk(rhn_path):
   for d in dirs:
       if d == 'modules' or root.startswith(rhn_path + "/modules"):
           fileutils.setPermsPath(os.path.join(root, d), group='apache', chmod=0o770)
       else:
           fileutils.setPermsPath(os.path.join(root, d), group='apache')
   for f in files:
       if root.startswith(rhn_path + "/modules"):
           fileutils.setPermsPath(os.path.join(root, f), group='apache', chmod=0o770)
       else:
           fileutils.setPermsPath(os.path.join(root, f), group='apache')

    In common/fileutils.py, line 303 and further:

    def setPermsPath(path, user=None, group='root', chmod=int('0750', 8)):
   """chown user.group and set permissions to chmod"""
   if isSUSE() and user is None:
       user = 'wwwrun'
   elif user is None:
       user = 'apache'
    · Share on TwitterShare on Facebook
  • andreas.dijkman
    andreas.dijkman Member Posts: 46 Bronze Badge
    edited February 12

    Yes, adding the argument owner='tomcat' fixed it:

            # update permissions
        rhn_path = os.path.join(CFG.MOUNT_POINT, 'rhn')
        fileutils.createPath(rhn_path)  # if the directory exists update ownership only
        for root, dirs, files in os.walk(rhn_path):
            for d in dirs:
                if d == 'modules' or root.startswith(rhn_path + "/modules"):
                    fileutils.setPermsPath(os.path.join(root, d), user='tomcat', group='apache', chmod=0o770)
                else:
                    fileutils.setPermsPath(os.path.join(root, d), group='apache')
            for f in files:
                if root.startswith(rhn_path + "/modules"):
                    fileutils.setPermsPath(os.path.join(root, f), user='tomcat', group='apache', chmod=0o770)
                else:
                    fileutils.setPermsPath(os.path.join(root, f), group='apache')

    After running a reposync with module-data, the ownership of the entire modules-directory is now tomcat:apache.

    Update

    Testcase:

    Schedule a (daily) reposync from the Spacewalk Interface or run it manually through the Spacewalk Interface. If you reposync a channel with module-data, the owner of the modules-directory is reset to apache by the setPermsPath-function. Reposync is run by taskomatic, which is running under user root, who can change the owner (back) to apache.

    Observe that the modules-directory (including subdirectories) is now owned by apache, and not tomcat.


    Fix:

    Add the argument owner='tomcat' to the setPermsPath-function so the modules-directory isn't (re)set to apache but to tomcat after a reposync, so the other cloning-tools and such can actually change the module-data.

    · Share on TwitterShare on Facebook
  • Laurence Rochfort-Oracle
    Laurence Rochfort-Oracle Member Posts: 81 Employee
    edited February 12

    @andreas.dijkman ,

    Channel cloning of modular channels from Web, Spacecmd, spacewalk-clone-by-date, and spacewalk-manage-channel-lifecycle all work with apache:apache permissions.

    Additionally, copying modular packages from one modular channel to another works with apache:apache permissions.

    · Share on TwitterShare on Facebook
  • andreas.dijkman
    andreas.dijkman Member Posts: 46 Bronze Badge

    Cloning of existing channels into new one, yes. But this is my case:

    Create/sync a channel, ol8-appstream in this case. Clone the channel, name it clone-ol8-appstream. Observe that the ol8-appstream-modules-directory has owner apache:apache and clone-ol8-appstream has tomcat:apache.

    Now sync ol8-appstream from upstream (for example yum.oracle.com), with the webinterface or by scheduling it, after there are some appstream-changes and module-data is imported again into the existing ol8-appstream-channel. Now observe that the entire modules-directory (including subdirectories) is changed to owner apache:apache, including the clone-ol8-appstream (which was previously tomcat:apache).

    Try the scenario you posted the logfile from in your post and run the command spacewalk-repo-sync -c ol8_appstream again at the end (with changed upstream module data) and check out the permissions of the modules data again. On my system, which is a vanilla OLM 2.10, all directories have apache:apache as owner. This is triggered by doing an spacewalk-repo-sync on any channel with module data, in the vanilla OL8-case, AppStream and CodeReady Builder.

    · Share on TwitterShare on Facebook
  • Laurence Rochfort-Oracle
    Laurence Rochfort-Oracle Member Posts: 81 Employee
    edited February 18

    @andreas.dijkman

    All channel manipulation operations will work with either apache:apache or tomcat:apache ownership. Both ownership options are valid.

    modules_ownership_cloning.txt

    If you require further assistance, please log a bug via Oracle Support.

    · Share on TwitterShare on Facebook
Sign In or Register to comment.