Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 02 15:31
    arvados-bot closed #157
  • Dec 02 15:31
    arvados-bot closed #158
  • Dec 01 07:19
    MajewskiKrzysztof opened #158
  • Dec 01 07:13
    MajewskiKrzysztof opened #157
  • Dec 01 07:07
    MajewskiKrzysztof closed #155
  • Dec 01 07:07
    MajewskiKrzysztof closed #156
  • Nov 30 14:33
    MajewskiKrzysztof opened #156
  • Nov 30 14:27
    MajewskiKrzysztof edited #155
  • Nov 30 14:26
    MajewskiKrzysztof edited #155
  • Nov 30 14:26
    MajewskiKrzysztof opened #155
  • Nov 23 10:04
  • Nov 16 21:57
    arvados-bot closed #153
  • Nov 16 21:46
    kinow synchronize #153
  • Nov 16 16:51
    lijiayong opened #154
  • Nov 16 16:26
  • Nov 15 22:05
    kinow opened #153
  • Nov 13 06:31
    kinow converted_to_draft #152
  • Nov 13 04:45
    kinow edited #152
  • Nov 13 04:44
    kinow opened #152
Tom Clegg
@tomclegg
I agree it would be easier to drop that capability. I'm really not sure whether anyone would miss it.
Is it hard to keep doing the same thing with the "follow" flag?
Peter Amstutz
@tetron
(I don't think the activity page works, on the covid-19 cluster, which has had some activity, everything is 0, not to mention it hasn't been updated for containers)
Tom Clegg
@tomclegg
Well. It's clearly harder than doing nothing. I mean is it even harder now than it was when we made the materialized view...
ah... interesting, I suspect the "logins" counter relies on wb1 to do something that wb2 doesn't (there are non-zero numbers on su92l)
at best that page is of questionable utility
Hm, didn't we have ideas about this when we were discussing changing the menu of permission types?
Peter Amstutz
@tetron
yes
sort of
"can_use_permissions"
Peter Amstutz
@tetron
yes although I'm not sure that actually enables this case
that would imply the read_only on the group record but then can_manage on the users
I have to be done for the night, my daughter is waiting for me to play with her, I think maybe I just have to re-add the notion of the 'follow' (or 'inherit permission') flag to the permission table
Tom Clegg
@tomclegg
yeah... changing the actual permission model might not be easier than that, unfortunately
Peter Amstutz
@tetron
ok, good night
Lucas Di Pentima
@ldipenti

@tomclegg I’m playing with arv-boot and integration tests, and I’ve found a couple of issues that I’m trying to solve. For example, the ws’s external url should have a /websocket path. Now I’m struggling a little with WebDAV, it seems keep-web isn’t listening on its internal port and on the logs I’m seeing:

[keep-web] 2020/05/07 15:49:22 WARNING: Error retrieving services list: Get "https://localhost:38959/arvados/v1/keep_services/accessible": x509: certificate signed by unknown authority (retrying in 3s)

I believe the rest of the services don’t complain about this because they all talk to each other through their internal URLs?

Lucas Di Pentima
@ldipenti
Hmm, tried to copy rootCA.crt to /etc/ssl/certs/ but it doesn’t seem to make any effect
Lucas Di Pentima
@ldipenti
@tomclegg Figured it out. Placement of the crt was /usr/local/share/ca-certificates. Do you think arvados-boot should be installing a explicit cert? I have the needed changes for review, if so.
Tom Clegg
@tomclegg
@ldipenti the "boot" stuff currently relies on TLS: Insecure: true -- so either that's not set in your config, or keep-web's keep client isn't paying attention to it
looks like it must be the latter, because arvados-boot sets cluster.TLS.Insecure = true
Lucas Di Pentima
@ldipenti
Yes, thanks. Last night I remembered about the Insecure flag after seeing th test fail on jenkins because it didn’t have permission to copy the cert :facepalm:
Tom Clegg
@tomclegg
Seems like we should make the same change to keep-web that we made to keepproxy, get keepstore endpoints directly from config file instead of keep_services api...
Lucas Di Pentima
@ldipenti
Ok, I’ll check those changes, thanks for the pointer!
Peter Amstutz
@tetron
@tomclegg oh, so the thing I wanted to talk to you about
to tighten up our definition of "role" and "project"
and plug the gaps of things that are technically possible but in a semantic gray area
I propose the following constraints:
1) group_class must be one of "role" or "project" anything else (or empty) is an error
2) a "role" cannot be an owner, but it can be tail_uuid for permission links
3) a "project" can be an owner, but cannot be tail_uuid for permission links
4) group_class field cannot change after creation
5) links with "link_class: permission" cannot change after creation
Peter Amstutz
@tetron
6) a "role" can only be owned by a user (not a project)
Tom Clegg
@tomclegg
So far that all sounds reasonable -- perhaps 6) should be a "role" can only be owned by system_user?
Peter Amstutz
@tetron
yea, I had that thought, in that case a "create" would assign it to system user and give a can_manage link to the user creating it
Tom Clegg
@tomclegg
suppose "who owns a role" and "who owns a permission link" are similar in that sense
Peter Amstutz
@tetron
sure
Tom Clegg
@tomclegg
(if you are the tail, or have manage permission on head, then you can do whatever you want with the permission link... and if not, owning the permission link is probably a mistake)
Peter Amstutz
@tetron
come to think of it, permission links are also automatically owned by the system user, I think?
so they already many not be mutable by mere mortals
Tom Clegg
@tomclegg
yeah it's possible we already dealt with that
Peter Amstutz
@tetron
(although they shouldn't be mutable at all -- have to double check)
great
then the only question is what the migration should do when it finds groups that violate these new rules
Tom Clegg
@tomclegg
right. Like a group that is both an object's owner_uuid, and a permission link's tail_uuid.
I suppose we just delete the permission links (or change their tail_uuid to system_user to make them a bit easier to recover/migrate manually) and log something?
(as an aside, I sure look forward to having a migration strategy like 1) leave old version running 2) run new version's migrations, follow advice, repeat as needed until it reports ok 3) start new version 4) turn off old version)
Peter Amstutz
@tetron
groups with no group_class (or an unrecognized group_class) could be inferred
unless they both own things are have outgoing links