Closed staeglis closed 3 years ago
ws_list is empty:
$ ws_list
/usr/local/bin/ws_list:106: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
config = yaml.load(open('/etc/ws.conf'))
can you show my your python version?
in your config you have default: tmp and you have an ACL (group_acl: admin) are you part of that group? If not, that warning is expected.
I think a fixed the ws_list warning in latest commit.
Yes I'm a member of the admin group. And the directory itself is created. But there is still no database. Do I have to create the database manually before I can allocate workspaces?
I think a fixed the ws_list warning in latest commit.
The issue still exist in ws_register at least
can you show my your python version?
It's python 3.8 on Ubuntu 20.04
primary or secondary group? compiled with cmake flag CHECK_ALL_GROUPS?
Am Fr., 15. Jan. 2021 um 09:50 Uhr schrieb staeglis < notifications@github.com>:
Yes I'm a member of the admin group.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/holgerBerger/hpc-workspace/issues/58#issuecomment-760759817, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEY2AVBZRNZT7VTYUAQQQDSZ76UXANCNFSM4WCTHVJA .
It's secondary group. User and group informations are provided through SSSD.
The issue remains after changing the CMakeList.txt regarding CHECK_ALL_GROUPS and after changing/removing group_acl
ok, that is unexpected....
can you give me output of with -d ?
Am Fr., 15. Jan. 2021 um 11:37 Uhr schrieb staeglis < notifications@github.com>:
It's secondary group. User and group informations are provided through SSSD.
The issue remains after changing the CMakeList.txt regarding CHECK_ALL_GROUPS and after changing/removing group_acl
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/holgerBerger/hpc-workspace/issues/58#issuecomment-760819321, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEY2AXR4TXBPU2KKLMDRWDS2ALELANCNFSM4WCTHVJA .
-d as option for ws_allocate?
$ ws_allocate -d 10 -n test
warn: you seem to have no access to your default workspace!?
Info: creating workspace.
Error: could not change permissions of database entry
/tmp/tmp-work/staeglis-test
remaining extensions : 2
remaining time in days: 10
Or this?
# cmake -DCHECK_ALL_GROUPS=TRUE .
-- Found terminfo
-- Found system YAML
-- LINKER_VAR: /usr/lib/x86_64-linux-gnu
-- Configuring done
-- Generating done
-- Build files have been written to: /root/hpc-workspace
sorry, I ment --debug please get latest commit 594048c45182a20c98defc1c6402febbefe720c6 and try with --debug this is for the warning
about the permission problem: can you show ls -ld of the Db diectory? ls -ld /tmp/tmp-db
Am Fr., 15. Jan. 2021 um 12:39 Uhr schrieb staeglis < notifications@github.com>:
-d as option for ws_allocate? $ ws_allocate -d 10 -n test warn: you seem to have no access to your default workspace!? Info: creating workspace. Error: could not change permissions of database entry /tmp/tmp-work/staeglis-test remaining extensions : 2 remaining time in days: 10 http://url
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/holgerBerger/hpc-workspace/issues/58#issuecomment-760891890, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEY2AVG2MCQULV7SWSND2LS2ASNZANCNFSM4WCTHVJA .
debug: primarygroup=ml
debug: no filesystem given, searching...
debug: searching dlclarge
debug: searching dlcsmall
debug: searching tmp
debug: fallback, using global default, ending search
debug: find_valid_fs:dlclarge
debug: find_valid_fs, has ACL, access denied.
debug: find_valid_fs, in group ACL, access granted (secondary).
debug: find_valid_fs, granted
debug: find_valid_fs:dlcsmall
debug: find_valid_fs, has ACL, access denied.
debug: find_valid_fs, in group ACL, access granted (secondary).
debug: find_valid_fs, granted
debug: find_valid_fs:tmp
debug: find_valid_fs, has ACL, access denied.
debug: find_valid_fs, in user ACL, access granted.
debug: find_valid_fs, granted
debug: moved default filesystem to front:tmp
debug: searching valid filesystems tmp
debug: searching valid filesystems dlcsmall
debug: searching valid filesystems dlclarge
Info: creating workspace.
Error: could not change permissions of database entry
/tmp/tmp-work/staeglis-test
remaining extensions : 2
remaining time in days: 10
$ ls -ld /tmp/tmp-db
drwxr-xr-x 3 dbuid dbgid 4096 Jan 14 13:51 /tmp/tmp-db
ok looks good, and the setuid-bit on ws_allocate is present?
should somehow like this $ ls -l bin/ws_allocate -rwsrwxr-x 1 root xxxxxx 9666344 Jan 15 13:25 bin/ws_allocate
and the filesystem has to allow sbits, which is default.
Yes:
$ ls -l /usr/local/bin/ws_allocate
-rwsr-xr-x 1 root root 3210928 Jan 15 13:42 /usr/local/bin/ws_allocate
but the db file is created? what does it look like permission wise?
No there is not database file:
$ ls -la /tmp/tmp-db/
total 48
drwxr-xr-x 3 kislurm kisconfig 4096 Jan 14 13:51 .
drwxrwxrwt 27 root root 36864 Jan 15 16:47 ..
drwxr-xr-x 2 kislurm kisconfig 4096 Jan 14 13:51 .removed
I assume it's right that /tmp/tmp-db is a directory
has sbin/ws_validate_config something to say? (I noticed a bug in that script last check in your case, fixed in latest commit)
and yes, the db is just a directory, that is correct.
ok if there is no file one can not change the permissions of it.. so far so good. But why can the file not be written? that is strange.
Can you provide a example database?
If I remove the following line, ws_allocate is working:
setegid(dbgid); seteuid(dbuid);
But his will cause trouble if the db is on a NFS. If thge dbuid/dbgid are unix groups/users the issue occurs too.
Ok I've mixed up the config entries dbuid and dbgid. But this doesn't solve the issue. It's working only if a give write acess for the database directory to everyone. I assume this isn't intended? The owner of the new db file is in this case dbuid/dbgid
Sorry, this was a classical layer 8 problem. The dbuid user hadn't write access to the database folder. Thank you very much for your help.
Hi,
even on as test workspace on /tmp I get the same issue:
The config
Best, Stefan