[yast-devel] webyast, some issues
So, another round of tests :-) - Permissions setup In theory, there are 2 groups of permissions: - the ones for the service, which allows it to read policykit permisions, execute scr/YaST calls, and do some packagekit stuff. - the per service ACLs, which represent resources, and that ones are used by the service to check if the logged user has permission (when it is a pam user), which are executed by the service if the user is authorized by using his powers coming from the permissions above. To quicly setup the permissions, policyKit-rights.rb uses polkit-auth $user -- explicit to see what permissions are on. This option excludes permissions set by adding a match tag on PolicyKit.conf, is that intented? The same things does then the system_check tag, which complains that some actions are not authorized for current user, even if they are using PolicyKit.conf (which is not explicit). CCing Marcus and Ludwig here :-) - Login slow It seems the health status (or something else) takes some time, and makes the impression login would take forever. - tests How are tests in all plugins supposed to be run? I am confused with some tasks being at the top-level, others shared in webservice-tasks, others specific to the webclient or service, and other stuff is implemented in script/something (why not a task?) - How is, in a similar fashion packaging done? (in order to integrate it to hudson). Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Duncan Mac-Vicar P. schrieb:
So, another round of tests :-)
- Permissions setup
In theory, there are 2 groups of permissions:
- the ones for the service, which allows it to read policykit permisions, execute scr/YaST calls, and do some packagekit stuff.
- the per service ACLs, which represent resources, and that ones are used by the service to check if the logged user has permission (when it is a pam user), which are executed by the service if the user is authorized by using his powers coming from the permissions above.
To quicly setup the permissions, policyKit-rights.rb uses polkit-auth $user -- explicit to see what permissions are on. This option excludes permissions set by adding a match tag on PolicyKit.conf, is that intented?
The same things does then the system_check tag, which complains that some actions are not authorized for current user, even if they are using PolicyKit.conf (which is not explicit).
I think we should not use PolicyKit.conf at all. It has been a workaround only during the beginning of WebYaST.
CCing Marcus and Ludwig here :-)
- Login slow
It seems the health status (or something else) takes some time, and makes the impression login would take forever.
Yes you are right. Patch evaluation takes so long. I think that will be a nice task for Ajax :-)
- tests
How are tests in all plugins supposed to be run? I am confused with some tasks being at the top-level, others shared in webservice-tasks, others specific to the webclient or service, and other stuff is implemented in script/something (why not a task?)
- How is, in a similar fashion packaging done? (in order to integrate it to hudson).
Duncan
-- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stefan Schubert napsal(a):
Duncan Mac-Vicar P. schrieb:
So, another round of tests :-)
- Permissions setup
In theory, there are 2 groups of permissions:
- the ones for the service, which allows it to read policykit permisions, execute scr/YaST calls, and do some packagekit stuff.
- the per service ACLs, which represent resources, and that ones are used by the service to check if the logged user has permission (when it is a pam user), which are executed by the service if the user is authorized by using his powers coming from the permissions above.
To quicly setup the permissions, policyKit-rights.rb uses polkit-auth $user -- explicit to see what permissions are on. This option excludes permissions set by adding a match tag on PolicyKit.conf, is that intented?
The same things does then the system_check tag, which complains that some actions are not authorized for current user, even if they are using PolicyKit.conf (which is not explicit).
I think we should not use PolicyKit.conf at all. It has been a workaround only during the beginning of WebYaST.
I also run into this problem in beginning. Problem is more difficult as policykit bindings used in backend and in dbus layer of YaST respect PolicyKit.conf so it cause at least confusion.
CCing Marcus and Ludwig here :-)
- Login slow
It seems the health status (or something else) takes some time, and makes the impression login would take forever.
Yes you are right. Patch evaluation takes so long. I think that will be a nice task for Ajax :-)
Yes, I plan work on it tomorrow when I be at work, I already prepare ajax stuff in patch module itself (it really need some improve as it time to much time, so maybe I change it little, because to filter is not ajax good when it time too much time to show the most important info on page).
- tests
How are tests in all plugins supposed to be run? I am confused with some tasks being at the top-level, others shared in webservice-tasks, others specific to the webclient or service, and other stuff is implemented in script/something (why not a task?)
I think that it is not good use own test task, as it cause some problems. I think we should prefere using general rake test task as I use it in language and time (I hope miso send my change)
- How is, in a similar fashion packaging done? (in order to integrate it to hudson).
It is in specific Rakefiles now....but It cause few problems. At first it package even things which is not in git (like my nbproject for netbeans) so I must manually exclude this. I think that it should be moved to general webservice tasks as check for uncommited (and unpushed) changes, clone repo and pack it with respect to the file where is specified exceptions.
Duncan
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Duncan Mac-Vicar P. <dmacvicar@suse.de> [Jul 15. 2009 00:48]:
- Login slow
It seems the health status (or something else) takes some time, and makes the impression login would take forever.
Looking at the Rails log, creating a (remote) session takes ~5 seconds on my system. This is hardly acceptable. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday 15 July 2009 14:21:35 Klaus Kaempf wrote:
* Duncan Mac-Vicar P. <dmacvicar@suse.de> [Jul 15. 2009 00:48]:
- Login slow
It seems the health status (or something else) takes some time, and makes the impression login would take forever.
Looking at the Rails log, creating a (remote) session takes ~5 seconds on my system. This is hardly acceptable.
Do we know where the bottleneck is and how to find it? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (5)
-
Duncan Mac-Vicar P.
-
Duncan Mac-Vicar Prett
-
josef reidinger
-
Klaus Kaempf
-
Stefan Schubert