Upgrade 6.2.2 to 2022.09.03 on RHEL 8.9

[Sandy McQuay]

Upgrading from 6.2.2 to 2022.09.03 on RHEL 8.9

New server is a VM.  My server team installed RHEL for me and in the process created an additional user/group before the hci user and staff group were created during the Cloverleaf 2022.09 install.

The new group snagged the group ID 1000, which is the group ID of staff on 6.2.2. The group ID of staff on the new server is 1002.

I tar’d up one of my 6.2.2 sites and untarred it into /cloverleaf/migrate then ran hcirootcopy for one site (hcirootcopy -s t_financial /cloverleaf/migrate).

Now, only hci user and group staff have permissions to the directories and files on the new server:

drwx——. 22 hci staff 4096 Oct 16 14:54 t_financial

While on the 6.2.2 server, permissions are set like this:

drwxrwxr-x. 19 hci staff 4096 Aug 20 10:54 t_financial

I can use chmod -R 755 to change permission on t_financial, will set rwxrwxr-x on all files and folders, but should I?  NetConfig on 6.2.2 only has -rw-rw-r– permissions.

Are the group ID’s causing this behavior?

Topic

[Jim Gilbert]

We found that it is the .profile in the /home/hci directory. if you change the umask setting you can copy over with the same permissions as the previous version. we found that setting it to all 000 “zeros” worked the best for us.

[Sandy McQuay]

Thanks @Jim Gilbert!

That worked . . . after I “deleted” the t_financial site (renamed the directory and removed the site in Server Administrator).  I couldn’t find any real documentation for deleting a site . . .

The permissions on the folder now are:

drwxrwxr-x. 22 hci staff 4096 Oct 18 15:15 t_financial

Underlying files and directories appear to be correct as well.

Fingers crossed!

 

[Jason Russell]

We had a similar issue, as Jim noted, the umask in your .profile (/home/hci/.profile) is what was causing issues. We keep all of our cloverleaf directories (and subortinate files) as 700 (drwx——.) our umask is the inverse of that, so it’s 077. When we initially started it was something off like 022.

Once the umask was set correctly, we had no issues.

For reference, we noticed the issue when we moved from RHEL 8.3 to 8.7 (We’re up to 8.10 now).

[Author]

Replies