Homelab, Linux, JS & ABAP (~˘▾˘)~
 

[CAP] Multitenant Job Scheduler – Fixing Scope issue

When I was integrating the Job Scheduler service into my Multitenant Application, I ran into the following JWT Token issue, when the Job Scheduler was calling my CAP action. Means the job creation was already working fine and was also displaying the right tenant for my job, but the Job Scheduler was not able to successfully call the given endpoint. This is the error I got in the logs:

Error: Jwt token with audience: [
'sb-a1e9d3b8-2bee-47db-xxxx-07e5a54aec1e!b180208|sap-jobscheduler!b3',
'uaa'
] is not issued for these clientIds: [
'sb-MyApp-mtdev-App!t180208',
'MyAp-mtdev-App!t180208'
].

After reading some of the great blogs from Carlos Roggan, I noticed that I forgot to grant the Job Scheduler the necessary authority to actual call my CAP action. So I added the following lines to the xs-security.json file

    {
      "name": "$XSAPPNAME.jobscheduler",
      "description": "Scope for Job Scheduler",
      "grant-as-authority-to-apps": [
        "$XSSERVICENAME(job-scheduler)"
      ]
    }

and also annotated my CAP action using the new scope @(requires: ['jobscheduler']).

I redeployed everything, but the issue still persists. 🙁

Turned out, for the standard plan, tokens are cached in Job Scheduler up to 12 hours.

https://help.sap.com/docs/job-scheduling/sap-job-scheduling-service/secure-access?locale=en-US

After waiting 12 hours, the endpoint was successfully called by the Job Scheduler. 🙂

[Shell] User and Group management & File permissions

  • User and Group management
    • id
    • useradd
      • -c – Full name
      • -e – Expiration date
      • -s – Default shell
      • -d – Home directory
    • passwd
    • usermod
      • -l – rename
      • -L – Lock
      • -U – unlock
    • userdel
      • -r – remove user data
    • groupadd
    • groupmod
    • gpasswd [-a -d -A] [user1, user2] [group]
    • newgrp [group]
  • su vs. su – vs. sudo
    • visudo
  • File permissions
    • UGO – User, Group, Other
    • RWX – Read, Write, Execute
    • chmod -R g+x (grant recursive execute permission to group)
      • r = 4
      • w = 2
      • x = 1
      • = 0
      • rwxrwxrwx = 777
      • rw-rw-rw- = 666
      • rwxrwxr–- = 774
      • rw-rw—- = 660
      • rw-r—–- = 640
    • chown
    • chgrp
    • umask

https://www.sluug.org/resources/presentations/2020/2020-02-12_permissions.pdf

[Proxmox] NFSv4 client saves files as “nobody” and “nogroup” on ZFS Share

I’m running a Proxmox Cluster with PVE1 and PVE2. On PVE2 a VM is running Debian Buster, which is mounting an zfs nfs share from PVE1. Inside the VM a script is running as root saving a backup on this nfs share. If I create a file locally (Test1) on PVE1, the owner is of course root. But since a few weeks the script running inside the VM is creating all files as nobody (Test2).

# ls -all /mnt/nfs/data
drwxr-xr-x  2 root  root       4096 Jul  5 07:19 Test1
drwxr-xr-x  2 nobody nogroup   4096 Jul  5 07:21 Test2

This is because root users are mapped to different user id’s and group’s when changing files on an nfs share. But until now, this was no problom when enabling nfs on a dataset via

zfs set sharenfs=on zpool/data

because the no_root_squash was set by default. But it looks like this was a changed in ZFS on Linux 0.8.3 and the no_root_squash option isn’t set by default anymore. To enable it again use:

zfs set sharenfs='rw,no_root_squash' zpool/data

Another way is exporting the folder via /etc/exports and adding the no_root_squash option.

# sudo nano /etc/exports
/zpool/data/ *(rw,no_subtree_check,sync,insecure,no_root_squash)

Run sudo exportfs -a after editing the exports file to enable these changes immediately.