Symlinks under "s3-config/access_keys" should contain a relative path rather absolute path

[anandhu-karattu]

Environment info

• NooBaa Version: noobaa-core-5.15.0-20240313.el9.x86_64 (4.15 down stream)
• Platform: Standalone RHEL 9.2

Actual behavior

We have a DR scenario with configuration backup/restore:

When an account is created, it creates a symlink under “s3-config/access_keys” directory.

[root@scale-2node-x-worker1 s3-config]# ls -lrt access_keys/
lrwxrwxrwx 1 root root 65 Mar 18 22:55 wwqNVMVquPBOfXIud5hK.symlink -> /gpfs/fs-ces-shared/new_path/ces/s3-config/accounts/account1.json

Use case:
Scale has a backup/restore feature which takes backup of configuration (everything under “s3-config” dir).
When user change the configuration path to a different FS, he can restore the old configuration.
However after restore, the “access_keys” directory still has the symlinks to old configuration path (absolute path). Thus access keys are no more working.
If I fix the symlinks to new absolute path, accounts become accessible again.
[root@scale-2node-x-worker1 access_keys]# ln -sfn /gpfs/fs-ces-shared_new/ces/s3-config/accounts/account1.json wwqNVMVquPBOfXIud5hK.symlink

Expected behavior

Symlinks should contain a relative path rather absolute path

More information - Screenshots / Logs / Other output

[naveenpaul1]

@anandhu-karattu I dont think adding relative path will fix this specific scenario you mentioned here.
Suppose user already have a symlink
wwqNVMVquPBOfXIud5hK.symlink -> /gpfs/fs-ces-shared/new_path/ces/s3-config/accounts/account1.json and we convert link to relative path to ../../../../../s3-config/accounts/account1.json but after restoration if user copy the account config files to folder /gpfs/fs-ces-shared/new_path/new_dir/ces/s3-config/accounts/ then the symlink will fail because new relative path should be ../../../../../s3-config/accounts/account1.json, Correct me if I am wrong.
cc : @guymguym @romayalon

[madhuthorat]

@anandhu-karattu I dont think adding relative path will fix this specific scenario you mentioned here. Suppose user already have a symlink wwqNVMVquPBOfXIud5hK.symlink -> /gpfs/fs-ces-shared/new_path/ces/s3-config/accounts/account1.json and we convert link to relative path to ../../../../../s3-config/accounts/account1.json but after restoration if user copy the account config files to folder /gpfs/fs-ces-shared/new_path/new_dir/ces/s3-config/accounts/ then the symlink will fail because new relative path should be ../../../../../s3-config/accounts/account1.json, Correct me if I am wrong. cc : @guymguym @romayalon

@naveenpaul1 The accounts/ and access_keys/ directory exist at the same level. So to have a symlink you can simply have:
wwqNVMVquPBOfXIud5hK.symlink -> ../accounts/account1.json

This will fix the issue in my view.

[guymguym]

@naveenpaul1 not sure I follow, why do you need the relative path to go all the way up to the root? these files have a closer shared ancestor which is the noobaa config root directory (which could be redirected to be under cesSharedRoot)...

To create that link from shell you would start from the target dir, and link a relative path like this for example

cd /etc/noobaa.conf.d/access_keys/
ln -s ../accounts/<name>.json <key>.symlink

[naveenpaul1]

@guymguym @madhuthorat I got it, will do the changes as you mentioned. Thank you.

[naveenpaul1]

@anandhu-karattu code is merged, You can test using upstream branch.

[anandhu-karattu]

Picking this up for verification in latest u/s build @naveenpaul1

[anandhu-karattu]

Verified on upstream build "noobaa-core-5.17.0-20240415.el9.x86_64"

[root@earth-x-worker1 access_keys]# ls -lrt
total 1
lrwxrwxrwx 1 root root 30 Apr 17 00:15 KYolnzku0k59X57fkM66.symlink -> ../accounts/account-35940.json

Now only relative path is available with symlink. Fix looks good.

[romayalon]

@anandhu-karattu thanks!
closing per the last comment